perf_counter: PERF_SAMPLE_ID and inherited counters
authorPeter Zijlstra <a.p.zijlstra@chello.nl>
Tue, 21 Jul 2009 11:19:40 +0000 (13:19 +0200)
committerPeter Zijlstra <a.p.zijlstra@chello.nl>
Wed, 22 Jul 2009 16:05:56 +0000 (18:05 +0200)
commit7f453c24b95a085fc7bd35d53b33abc4dc5a048b
tree63d2b80acb3095a3e1a56c69d20a8137a1337aed
parent573402db02746179b3f95f83a11a787501f52d0a
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.

[Does change the ABI a little, but I see no other way out]

Suggested-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1248095846.15751.8781.camel@twins>
include/linux/perf_counter.h
kernel/perf_counter.c
tools/perf/builtin-annotate.c
tools/perf/builtin-report.c