Re: Direct execlists submission

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: Direct execlists submission
Date: Mon, 14 May 2018 15:54:34 +0100	[thread overview]
Message-ID: <152630967443.18532.14081887920198521982@mail.alporthouse.com> (raw)
In-Reply-To: <152629354524.18532.16724655744185362384@mail.alporthouse.com>

Quoting Chris Wilson (2018-05-14 11:25:45)
> Quoting Tvrtko Ursulin (2018-05-14 11:11:54)
> > 
> > On 14/05/2018 10:37, Chris Wilson wrote:
> > > Continuing the discussion with the latest refactorings, however I ran
> > > some tests to measure the impact on system (!i915) latency,
> > > using igt/benchmarks/gem_syslatency -t 120
> > > 
> > > drm-tip:
> > >       latency mean=1.211us max=10us (no load)
> > >       latency mean=2.611us max=83us (i915)
> > > 
> > >          latency mean=1.720us max=833us (no load, bg writeout)
> > >          latency mean=3.294us max=607us (i915, bg writeout)
> > > 
> > > this series:
> > >          latency mean=1.280us max=15us (no load)
> > >          latency mean=9.688us max=1271us (i915)
> > > 
> > >          latency mean=1.712us max=1026us (no load, bg writeout)
> > >          latency mean=14.347us max=489850us (i915, bg writeout)
> > > 
> > > That certainly takes the shine off directly using the tasklet for
> > > submission from the irq handler. Being selfish, I still think we can't
> > > allow the GPU to stall waiting for ksoftirqd, but at the same time we
> > > need to solve the latency issues introduced elsewhere.

> > But now with this data it looks like a quite significant regression even 
> > if it fixes the rthog test case. So I don't know where this leaves us. :I

The ginormous writeout latency is a bit inconsistent. What remains
consistent is that with direct submission, latency with i915 loaded
remains around 10us versus 1us unloaded. The difference for direct
submission is that the latency and i915 throughput remains the same even
with bg writeout (with ksoftirqd there is a very noticeable fall off).

I've still no clue as what causes the latency to spike so badly with bg
write out.

As for the 10us latency, I think that is just i915 hogging the cpu to
handle the flow onto GPU, so the "fairness" issue that ksoftirqd seeks
to prevent (rather than a side-effect of irqoff, as the irqoff periods
do not change that much due to execlists_dequeue being the brunt of the
work).

I no longer think the sky is falling, or that these bad results are
anything more than something we can and should improve. I think the
protection from ksoftirqd is definitely more important for us.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx