| Message ID | 20190211135040.1234-2-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex | expand |
Chris Wilson <chris@chris-wilson.co.uk> writes: > We impose upon ourselves a strict timeout for resets (to ensure forward > progress by use of a failsafe). Prefer to use the expedited > synchronisation function in this case to reduce the likelihood of a > spurious delay being treated as a deadlock. 5 seconds of spurious delay? Well, better to rule this one out, Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Mika Kuoppala <mika.kuoppala@intel.com> > --- > drivers/gpu/drm/i915/i915_reset.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c > index c2b7570730c2..c1b53533ada6 100644 > --- a/drivers/gpu/drm/i915/i915_reset.c > +++ b/drivers/gpu/drm/i915/i915_reset.c > @@ -1138,7 +1138,7 @@ static void i915_reset_device(struct drm_i915_private *i915, > intel_prepare_reset(i915); > > /* Flush everyone using a resource about to be clobbered */ > - synchronize_srcu(&error->reset_backoff_srcu); > + synchronize_srcu_expedited(&error->reset_backoff_srcu); > > mutex_lock(&error->wedge_mutex); > i915_reset(i915, engine_mask, reason); > -- > 2.20.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Mika Kuoppala (2019-02-11 15:13:19) > Chris Wilson <chris@chris-wilson.co.uk> writes: > > > We impose upon ourselves a strict timeout for resets (to ensure forward > > progress by use of a failsafe). Prefer to use the expedited > > synchronisation function in this case to reduce the likelihood of a > > spurious delay being treated as a deadlock. > > 5 seconds of spurious delay? Past experience with rcu says over 30s is not unheard of; though it does start to complain if the system skips over 120s without an rcu grace period. > Well, better to rule this one out, Ulterior motive is that we still want fast resets :) We shouldn't upset the RT crowd too much as we are only using this sparingly. -Chris
diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c index c2b7570730c2..c1b53533ada6 100644 --- a/drivers/gpu/drm/i915/i915_reset.c +++ b/drivers/gpu/drm/i915/i915_reset.c @@ -1138,7 +1138,7 @@ static void i915_reset_device(struct drm_i915_private *i915, intel_prepare_reset(i915); /* Flush everyone using a resource about to be clobbered */ - synchronize_srcu(&error->reset_backoff_srcu); + synchronize_srcu_expedited(&error->reset_backoff_srcu); mutex_lock(&error->wedge_mutex); i915_reset(i915, engine_mask, reason);
We impose upon ourselves a strict timeout for resets (to ensure forward progress by use of a failsafe). Prefer to use the expedited synchronisation function in this case to reduce the likelihood of a spurious delay being treated as a deadlock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> --- drivers/gpu/drm/i915/i915_reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)