[Intel-gfx] [PATCH i-g-t 3/3] i915/gem_exec_fence: Avoid long preempt-off sleeps

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-11-13 10:54:58)
> 
> On 08/11/2019 14:22, Chris Wilson wrote:
> > The kernel is now enforcing that clients are not allowed to block higher
> > priority contexts from accessing the GPU; one is no longer allowed to
> > sleep for a second hogging the GPU. Reduce the sleep down to 50ms, short
> > enough not to anger the preempt-off checks while long enough for any
> > ordinary GPU work to complete.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >   tests/i915/gem_exec_fence.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
> > index 4e8bdd7b3..002120bf3 100644
> > --- a/tests/i915/gem_exec_fence.c
> > +++ b/tests/i915/gem_exec_fence.c
> > @@ -348,7 +348,8 @@ static void test_fence_await(int fd, unsigned ring, unsigned flags)
> >               i++;
> >       }
> >   
> > -     sleep(1);
> > +     /* Long, but not too long to anger preemption disable checks */
> > +     usleep(50 * 1000); /* 50 ms, typical preempt reset is 150+ms */
> 
> Was the point of this sleep two-fold: 1) allow spinner to start (use 
> polling spinner?) and allow forked children to submit (use pipe sync?)?

It was 3: wait long enough so we could be reasonably sure that the
children were indeed waiting and given the opportunity would not run
ahead of the parent.

This is a very loose, runs anywhere test. Revised variants are in
gem_exec_scheduler, which I like to think are a bit more precise.
Although I think the general test concept of "encouraging the children to
run first" could do with a little more exploration, as therein are where
the bugs lie.
-Chris