Re: [RFC 0/5] Per-client engine stats

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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.ursulin@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