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.
You dropped direct submit on idle from this incarnation, why?
Before the above data my concern was that i915_tasklet in its current
form does not buy us anything and adds boilerplate code. I was
suggesting two alternatives, either no i915_tasklet at all, or
different, more functional and self-contained version which you said
wouldn't work with some future code.
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
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
