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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxx>

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux