On 26/11/2019 17:08, Tvrtko Ursulin wrote:
On 26/11/2019 17:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-26 17:00:53)
On 26/11/2019 16:47, Chris Wilson wrote:
Following 58b4c1a07ada ("drm/i915: Reduce nested
prepare_remote_context()
to a trylock"), we punt to the caller if the local intel_context
happens to be busy as we try to rewrite the sseu (due to retiring in
another thread). As the interlude should be short, spin until the lock
is available.
The regret for using mutex_trylock() and not an atomic insertion of the
barrier is growing...
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 2ea4790f3721..571cc996577c 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1197,7 +1197,10 @@ __sseu_test(const char *name,
if (ret)
goto out_pm;
- ret = intel_context_reconfigure_sseu(ce, sseu);
+ do {
+ ret = intel_context_reconfigure_sseu(ce, sseu);
+ cond_resched();
+ } while (ret == -EAGAIN);
if (ret)
goto out_spin;
Hm I looked at the selftests, saw error is correctly propagated, and
concluded it will be fine. I missed the problem selftests will not
actually retry. But wait, can we even count that userspace will if all
of a sudden ctx.set_param starts returning -EAGAIN sporadically? Feels
like we may need to revert.
We invoke the principle of drmIoctl() catches -EAGAIN.
I'm not comfortable with that. :( Not least how we are saying not to use
libdrm. man 2 ioctl does not mention -EAGAIN. :(
Or duct tape by looping in set_sseu as well?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
