Re: perf_counters issue with PERF_SAMPLE_GROUP

[stephane eranian <eranian@googlemail.com>]

Hi,

Another thing that occurred to me  while using PERF_SAMPLE_GROUP
is about that unique ID which you get out of read() with PERF_FORMAT_ID.

That number if generated by the kernel and it is a globally incrementing
64-bit counter.

An application may not get subsequent numbers even though it is issuing
perf_open_counter() in sequence. Another applications may cause the
number to change.

I believe this is not very convenient because imagine in your signal handler
you parse the GROUP and you want to relate id to the event. You need
to have a lookup table.

I believe it would be more convenient if the tool could pass a 64-bit number
itself when the event is created. It would get it back as part of
PERF_SAMPLE_GROUP.
The id could then be more related to the tool's data structure, no need for a
lookup table, overall more efficient. If I recall, this is what
epoll() can do and
this is very convenient.