Quoting Tvrtko Ursulin (2020-03-09 18:31:17) > From: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > > 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx