Commit 7f310a5d authored by Eric B Munson's avatar Eric B Munson Committed by Ingo Molnar

perf_event: Fix broken calc_timer_values()

We detected a serious issue with PERF_SAMPLE_READ and
timing information when events were being multiplexing.

Samples would have time_running > time_enabled. That
was easy to reproduce with a libpfm4 example (ran 3
times to cause multiplexing on Core 2):

 $ syst_smpl -e uops_retired:freq=1 &
 $ syst_smpl -e uops_retired:freq=1 &
 $ syst_smpl -e uops_retired:freq=1 &
 IIP:0x0000000040062d ... PERIOD:2355332948 ENA=40144625315 RUN=60014875184
 syst_smpl: WARNING: time_running > time_enabled
	63277537998 uops_retired:freq=1 , scaled

The bug was not present in kernel up to (and including) 3.0. It turns
out the bug was introduced by the following commit:

commit c4794295

    events: Move lockless timer calculation into helper function

The parameters of the function got reversed yet the call sites
were not updated to reflect the change. That lead to time_running
and time_enabled being swapped. That had no effect when there was
no multiplexing because in that case time_running = time_enabled
but it would show up in any other scenario.
Signed-off-by: default avatarStephane Eranian <eranian@google.com>
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20110829124112.GA4828@quadSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
parent a8d757ef
...@@ -3396,8 +3396,8 @@ static int perf_event_index(struct perf_event *event) ...@@ -3396,8 +3396,8 @@ static int perf_event_index(struct perf_event *event)
} }
static void calc_timer_values(struct perf_event *event, static void calc_timer_values(struct perf_event *event,
u64 *running, u64 *enabled,
u64 *enabled) u64 *running)
{ {
u64 now, ctx_time; u64 now, ctx_time;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment