Quoting Tvrtko Ursulin (2020-03-09 18:31:17) > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > Another re-spin of the per-client engine busyness series. Highlights from this > version: > > * Different way of tracking runtime of exited/unreachable context. This time > round I accumulate those per context/client and engine class, but active > contexts are kept in a list and tallied on sysfs reads. > * I had to do a small tweak in the engine release code since I needed the > GEM context for a bit longer. (So I can accumulate the intel_context runtime > into it as it is getting freed, because context complete can be late.) > * PPHWSP method is back and even comes first in the series this time. It still > can't show the currently running workloads but the software tracking method > suffers from the CSB processing delay with high frequency and very short > batches. I bet it's ksoftirqd, but this could be quite problematic for us. gem_exec_nop/foo? I wonder if this also ties into how much harder it is to saturate the GPU with nops from userspace than it is from the kernel. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
