Re: [PATCH] perf_counter: Always return the parent counter id to userspace

Anton Blanchard
2009-07-22T05:14:25Z

Hi Peter,

> Hmm, ok, so how about something like this:
>
> ---
> Subject: perf_counter: PERF_SAMPLE_ID and inherited counters
>
> Anton noted that for inherited counters the counter-id as provided by
> PERF_SAMPLE_ID isn't mappable to the id found through PERF_RECORD_ID
> because each inherited counter gets its own id.
>
> His suggestion was to always return the parent counter id, since that is
> the primary counter id as exposed. However, these inherited counters
> have a unique identifier so that events like PERF_EVENT_PERIOD and
> PERF_EVENT_THROTTLE can be specific about which counter gets modified,
> which is important when trying to normalize the sample streams.
>
> This patch removes PERF_EVENT_PERIOD in favour of PERF_SAMPLE_PERIOD,
> which is more useful anyway, since changing periods became a lot more
> common than initially thought -- rendering PERF_EVENT_PERIOD the less
> useful solution (also, PERF_SAMPLE_PERIOD reports the more accurate
> value, since it reports the value used to trigger the overflow, whereas
> PERF_EVENT_PERIOD simply reports the requested period changed, which
> might only take effect on the next cycle).
>
> This still leaves us PERF_EVENT_THROTTLE to consider, but since that
> _should_ be a rare occurrence, and linking it to a primary id is the
> most useful bit to diagnose the problem, we introduce a
> PERF_SAMPLE_STREAM_ID, for those few cases where the full reconstruction
> is important.

I gave it a try and the perf.data results make much more sense.
Thanks!

Anton