[Intel-gfx] [PATCH] RFC drm/i915: Slaughter the thundering i915_wait_request herd

[Chris Wilson]

On Fri, Nov 27, 2015 at 01:01:12PM +0000, Chris Wilson wrote:
> On Fri, Nov 27, 2015 at 12:11:32PM +0000, Tvrtko Ursulin wrote:
> > 
> > Hi,
> > 
> > On 31/10/15 10:34, Chris Wilson wrote:
> > >One particularly stressful scenario consists of many independent tasks
> > >all competing for GPU time and waiting upon the results (e.g. realtime
> > >transcoding of many, many streams). One bottleneck in particular is that
> > >each client waits on its own results, but every client is woken up after
> > >every batchbuffer - hence the thunder of hooves as then every client must
> > >do its heavyweight dance to read a coherent seqno to see if it is the
> > >lucky one. Alternatively, we can have one worker responsible for wakeing
> > >after an interrupt, checking the seqno and only wakeing up the clients
> > >who are complete. The disadvantage is that in the uncontended scenario
> > >(i.e. only one waiter) we incur an extra context switch in the wakeup
> > >path - though that should be mitigated somewhat by the busywait we do
> > >first before sleeping.
> > 
> > Could you explain the design in a bit more detail in the commit message?
> 
> One worker responsible for waking up after an interrupt and waking
> clients who are complete?

The more kthready design would be one global irq worker. That means we
can save quite a bit by elimitinating the separate waitqueues. The
interaction between spin-request and the kthread wasn't so simple (and
that really was the deciding factor in writing the patch).

So kirq-i915? Let's see what it takes to transform from kworker to
kthread.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre