[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1264752266.4283.2121.camel@laptop>
Date: Fri, 29 Jan 2010 09:04:26 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: mingo@...e.hu
Cc: eranian@...gle.com, linux-kernel@...r.kernel.org
Subject: [PATCH 5/4] perf_events: Fix sample_period transfer on inherit
Subject: perf_events: Fix sample_period transfer on inherit
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Date: Thu Jan 28 12:34:07 CET 2010
One problem with frequency driven counters is that we cannot predict
the rate at which they trigger, therefore we have to start them at
period=1, this causes a ramp up effect. However, if we fail to
propagate the stable state on fork each new child will have to ramp up
again. This can lead to significant artifacts in sample data.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
---
kernel/perf_event.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
Index: linux-2.6/kernel/perf_event.c
===================================================================
--- linux-2.6.orig/kernel/perf_event.c
+++ linux-2.6/kernel/perf_event.c
@@ -5011,8 +5011,15 @@ inherit_event(struct perf_event *parent_
else
child_event->state = PERF_EVENT_STATE_OFF;
- if (parent_event->attr.freq)
- child_event->hw.sample_period = parent_event->hw.sample_period;
+ if (parent_event->attr.freq) {
+ u64 sample_period = parent_event->hw.sample_period;
+ struct hw_perf_event *hwc = &child_event->hw;
+
+ hwc->sample_period = sample_period;
+ hwc->last_period = sample_period;
+
+ atomic64_set(&hwc->period_left, sample_period);
+ }
child_event->overflow_handler = parent_event->overflow_handler;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists