Re: comments on Performance Counters for Linux (PCL)

[stephane eranian]

On Fri, May 29, 2009 at 10:32 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> On Thu, 2009-05-28 at 18:25 +0200, Peter Zijlstra wrote:
>> > Â 10/ Group event buffer entry
>> >
>> > Â Â Â ÂThis is activated by setting the PERF_RECORD_GROUP in the record_type
>> > Â Â Â Âfield. ÂWith this bit set, the values of the other members of the
>> > Â Â Â Âgroup are stored sequentially in the buffer. To help figure out which
>> > Â Â Â Âvalue corresponds to which event, the current implementation also
>> > Â Â Â Âstores the raw encoding of the event.
>> >
>> > Â Â Â ÂThe event encoding does not help figure out which event the value refers
>> > Â Â Â Âto. There can be multiple events with the same code. This does fit the
>> > Â Â Â ÂAPI model where events are identified by file descriptors.
>> >
>> > Â Â Â ÂThe file descriptor must be provided and not the raw encoding.
>>
>> OK, sounds sensible.
>
> This can't actually be done, fds can change, and there is no struct
> file* to fd map.

The API must define an order in which values are stored. Otherwise
how would the application figure out what they correspond to in the
group.

Explain to me what you mean by fds can change. Are you thinking
about dup()+close() for instance?

> If the config isn't good enough, the best we could do is something
> unique per instance.
>
Config isn't good enough for sure. For instance, I could be sampling
the same generic PERF_CPU_COUNT_CYCLES twice in the same
group, once at the user level only (exclude_kernel=1), and once at
the kernel level only (exclude_user=1), but the two config values
would be identical.

If there is no backmapping, then you could get by perhaps by having
the API guarantee that values are stored in the order events were
originally chained in the group. If that does not work, then you need
to emit a unique cookie per fd and let the application maintain a mapping
table.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/