[Intel-gfx] [PATCH igt] igt/gem_exec_latency: Wire up an interloper for preemption

[Michał Winiarski]

On Thu, Oct 26, 2017 at 12:04:11PM +0100, Chris Wilson wrote:
> Quoting Michał Winiarski (2017-10-26 11:52:31)
> > On Thu, Oct 26, 2017 at 08:31:27AM +0100, Chris Wilson wrote:
> > > For measuring the cost of preemption, inject a low priority spinner
> > > between the two measurements; the difference between the preemption and
> > > the normal dispatch includes both the cost of the spinner dispatch and
> > > of preempting it. Close enough for us to estimate the cost of
> > > preemption, though we don't measure the cost of preemption on the local
> > > ring!
> > 
> > And as expected, we're seeing more delay with GuC, probably from worker
> > scheduling delay (~2ms on my SKL if I'm reading the results correctly).
> 
> Don't look at bxt then ;) Another order or magnitude.
> 
> Most of that can be ascribed to using a worker, so we should be able to
> pare it back somewhat. Just the idea that the GuC may take 10ms to
> respond to a request is a bit disconcerting!

Naively replacing send_mutex with spinlock brings us back into tens of
microseconds range.

> 
> Do we have to wait for the ack from the preempt request? Could we farm
> that off to some other poor task? Then we would be in a position to
> avoid that mutex and process-context worker. Oh well, you probably
> already have ideas and plans for replacing that mutex :)
> -Chris

Error handling becomes more problematic (but doable... we're not doing anything
that affects execution while waiting for preemption to complete).
I was thinking about fast-path for preemption when it responds with a reasonable
amount of time, with fallback to worker when it doesn't.

-Michał