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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
