[Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] i915/gem_exec_scheduler: Exercise priority inversion from resource contention

[Daniel Vetter]

On Fri, Nov 8, 2019 at 10:22 PM Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> Quoting Daniel Vetter (2019-11-08 21:13:13)
> > On Fri, Nov 8, 2019 at 9:49 PM Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > >
> > > One of the hardest priority inversion tasks to both handle and to
> > > simulate in testing is inversion due to resource contention. The
> > > challenge is that a high priority context should never be blocked by a
> > > low priority context, even if both are starving for resources --
> > > ideally, at least for some RT OSes, the higher priority context has
> > > first pick of the meagre resources so that it can be executed with
> > > minimum latency.
> > >
> > > userfaultfd allows us to handle a page fault in userspace, and so
> > > arbitrary impose a delay on the fault handler, creating a situation
> > > where a low priority context is blocked waiting for the fault. This
> > > blocked context should not prevent a high priority context from being
> > > executed. While the userfault tries to emulate a slow fault (e.g. from a
> > > failing swap device), it is unfortunately limited to a single object
> > > type: the userptr. Hopefully, we will find other ways to impose other
> > > starvation conditions on global resources.
> > >
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >
> > So rt-ww_mutexes?
> >
> > I don't think we want/should do that on the first round of rolling out
> > ww_mutex in i915.
>
> It works today. And will continue working across any conversion.

Isn't that just an artifact of how we retry userptr page-in? I think
if we'd do this check with other objects, then it'll fall apart ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch