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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
