[Intel-gfx] [PATCH i-g-t] i915/gem_map_gtt: Escape from slow forked GTT access

[Chris Wilson]

Quoting Mika Kuoppala (2019-09-24 13:44:54)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > Beware the slithy t'oves.
> >
> > Forked GTT access on icl is notoriously slow, so rather than spend an
> > eternity checking the whole object, check for a completion event after
> > handling the pagefault. It's is the race of the pagefault vs reset that
> > we care most about, and we expect the bug to result in the pagefault
> > being blocked indefinitely, so checking afterwards does not reduce
> > coverage.
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > ---
> >  tests/i915/gem_mmap_gtt.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
> > index 0428a1372..91da5a37b 100644
> > --- a/tests/i915/gem_mmap_gtt.c
> > +++ b/tests/i915/gem_mmap_gtt.c
> > @@ -602,6 +602,9 @@ test_hang(int fd)
> >  
> >                               gtt[0][x] = patterns[next_pattern];
> >                               gtt[1][x] = patterns[next_pattern];
> > +
> > +                             if (READ_ONCE(control->done))
> > +                                     break;
> 
> The hang would have manifested itself on a previous loop
> already.
> 
> So you could life the exit condition before the writes.

The writes may also cause a fresh fault. The idea was to simply check
more frequently than once per object -- so long as we check within 2s of
the termination request, we are good.
-Chris