[Intel-gfx] [PATCH 02/19] drm/i915: Defer final intel_wakeref_put to process context

Chris Wilson chris at chris-wilson.co.uk
Thu Aug 8 15:00:51 UTC 2019


Quoting Mika Kuoppala (2019-08-08 15:47:07)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > As we need to acquire a mutex to serialise the final
> > intel_wakeref_put, we need to ensure that we are in process context at
> > that time. However, we want to allow operation on the intel_wakeref from
> > inside timer and other hardirq context, which means that need to defer
> > that final put to a workqueue.
> >
> > Inside the final wakeref puts, we are safe to operate in any context, as
> > we are simply marking up the HW and state tracking for the potential
> > sleep. It's only the serialisation with the potential sleeping getting
> > that requires careful wait avoidance. This allows us to retain the
> > immediate processing as before (we only need to sleep over the same
> > races as the current mutex_lock).
> >
> > v2: Add a selftest to ensure we exercise the code while lockdep watches.
> > v3: That test was extremely loud and complained about many things!
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111295
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=111245
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=111256
> > Fixes: 18398904ca9e ("drm/i915: Only recover active engines")
> > Fixes: 51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref")
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> 
> Ok, this was discussed on the other submission thread and
> confusion cleared. There was no aim for implicit sync
> for gem_wait but rather refine the resolution.
> 
> The test looked vicious enough, for both domains so
> we should notice if things fly apart.
> 
> Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>

This is one of those that is difficult to reason without tests and
difficult to nail down in tests. I'm sure there's plenty of refinement
to come. :|

Thanks,
-Chris


More information about the Intel-gfx mailing list