On 15/02/2018 09:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-02-15 09:44:58)
On 14/02/2018 19:20, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-02-14 18:50:30)
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Another re-post of my earlier, now slightly updated work, to expose a DRM client
hierarchy in sysfs in order to enable a top like tool:
So what I don't like about it is that it is a new interface in sysfs. We
already have a PMU interface for statistics and would rather see that
extended than abandoned. If perf can handle new processes coming and
going, surely we can handle new clients? :|
I don't think it means abandoning the PMU, just that I don't see it
suitable for this use case.
Even if we go with adding a PMU task mode, that is a separate thing from
this. It would allow profiling of a single task, but not enumerating and
profiling all clients/tasks from perf/PMU.
I think perf top seems to handle processes coming and going, so I don't
think it's a fundamental limitation of perf, just our understanding :)
I'd rather have one interface to maintain :)
Referencing my old branch when I barely started on per-task PMU, I think
that the idea was to add another i915 PMU instance which allows events
with tasks contexts.
Then in the implementation we would something like
i915_get_engine_busy_for_task(event->ctx->task).
This would work for "perf stat -e i915/rcs0-busy some-program".
But not for perf top - that one actually creates sampling counters which
need to provide things like PIDs and call-chains on each sample and I
don't see that we can ever do this.
Ignoring "perf top", we could implement a top like tool using the above
described new per-task PMU, but with two limitations:
1. No per-client support - only per-task.
2. More overhead - need a data structure, plus it's management, to map
from tasks to lists of drm clients etc.
My point is that I did not see the sysfs interface as a substantial
additional burden. Apart from the sysfs management bits, the rest is
actually building blocks for per-task PMU. Because the solution from
point 2 above would still need to aggregate the per-client stats, after
it is able to walk per-task clients.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
