On Fri, Nov 8, 2019 at 10:22 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > Quoting Daniel Vetter (2019-11-08 21:13:13) > > On Fri, Nov 8, 2019 at 9:49 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > > > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
