Re: perf_counters issue with PERF_SAMPLE_GROUP

[stephane eranian]

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.
--
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/