[Intel-gfx] [PATCH igt 2/3] igt/gem_exec_schedule: Basic tests for preemption

[Chris Wilson]

Quoting Michał Winiarski (2017-08-17 15:39:12)
> On Thu, Aug 03, 2017 at 01:30:28PM +0100, Chris Wilson wrote:
> > We queue N low priority hanging batches across the engines
> > and check that out high priority write over takes them.
> 
> s/out/our
> 
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> I'm getting stuck on throttle when spawning 10+ spin_batch instances.

Which throttle? <100 spin batches and we won't be blocking on the ring.
Hmm, a different of this test will create a new low-prio context for
each spinner. The first variant will allow the low-prio requests to be
merged together, so we should always be occupying 2 slots. Then if we
add a spinner from a new context, we increase the number of slots the
high prio has to bypass. The intention was to make sure that for
whatever configuration of elsp we could preempt successfully.

> Other than that - the tests look good, simple and quick to execute.
> (cross-engine failing in my tree... but that's a good thing!)
> I thought about adding different spin_batch variants rather than adding
> MI_ARB_CHK by default, but I guess it shouldn't matter (and if it does, we
> should notice something in other tests).

I was surprised that MI_BB_START wasn't a preemption point. The only
downside is that we don't have a non-preemption variant. If need be we
add flags to spin_batch. There are still a few users who could be
converted to spin_batch if the interface were a little more flexible -
including igt_hang.
-Chris