Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On 12/19/2017 5:07 PM, Peter Zijlstra wrote: On Tue, Dec 19, 2017 at 03:08:58PM -0500, Liang, Kan wrote: This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period() simply _cannot_ do the right thing when we auto reload the counter. I think it should be OK to call it in first place. For x86_perf_event_update(), the reload_times will tell if it's auto reload. Both period_left and event->count are carefully recalculated for auto reload. How does prev_count make sense when we've already reloaded a bunch of times? Same as non-auto-reload, it's the 'left' (unfinished) period from last time. The period for the first record should always be the 'left' period no matter on which case. For auto-reload, it doesn't need to increase the prev_count with the reload. Because for later records, the period should be exactly the same as the reload value. To calculate the event->count, For auto-reload, the event->count = prev_count + (reload times - 1) * reload value + gap between PMI trigger and PMI handler. For non-auto-reload, the event->count = prev_count + gap between PMI trigger and PMI handler. The 'prev_count' is same for both auto-reload and non-auto-reload. The gap is a little bit tricky for auto-reload. Because it starts from -reload_value. But for non-auto-reload, it starts from 0. "delta += (reload_val << shift);" is used to correct it. For x86_perf_event_set_period(), there is nothing special needed for auto reload. The period is fixed. The period_left from x86_perf_event_update() is already handled. Hurm.. I see. But rather than make an ever bigger trainwreck of things, I'd rather you just write a special purpose intel_pmu_save_and_restart() just for AUTO_RELOAD. OK. I will do it in V2. Thanks, Kan
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On 12/19/2017 5:07 PM, Peter Zijlstra wrote: On Tue, Dec 19, 2017 at 03:08:58PM -0500, Liang, Kan wrote: This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period() simply _cannot_ do the right thing when we auto reload the counter. I think it should be OK to call it in first place. For x86_perf_event_update(), the reload_times will tell if it's auto reload. Both period_left and event->count are carefully recalculated for auto reload. How does prev_count make sense when we've already reloaded a bunch of times? Same as non-auto-reload, it's the 'left' (unfinished) period from last time. The period for the first record should always be the 'left' period no matter on which case. For auto-reload, it doesn't need to increase the prev_count with the reload. Because for later records, the period should be exactly the same as the reload value. To calculate the event->count, For auto-reload, the event->count = prev_count + (reload times - 1) * reload value + gap between PMI trigger and PMI handler. For non-auto-reload, the event->count = prev_count + gap between PMI trigger and PMI handler. The 'prev_count' is same for both auto-reload and non-auto-reload. The gap is a little bit tricky for auto-reload. Because it starts from -reload_value. But for non-auto-reload, it starts from 0. "delta += (reload_val << shift);" is used to correct it. For x86_perf_event_set_period(), there is nothing special needed for auto reload. The period is fixed. The period_left from x86_perf_event_update() is already handled. Hurm.. I see. But rather than make an ever bigger trainwreck of things, I'd rather you just write a special purpose intel_pmu_save_and_restart() just for AUTO_RELOAD. OK. I will do it in V2. Thanks, Kan
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On Tue, Dec 19, 2017 at 11:07:09PM +0100, Peter Zijlstra wrote: > On Tue, Dec 19, 2017 at 03:08:58PM -0500, Liang, Kan wrote: > > > This all looks very wrong... In auto reload we should never call > > > intel_pmu_save_and_restore() in the first place I think. > > > > > > Things like x86_perf_event_update() and x86_perf_event_set_period() > > > simply _cannot_ do the right thing when we auto reload the counter. > > > > > > > I think it should be OK to call it in first place. > > For x86_perf_event_update(), the reload_times will tell if it's auto reload. > > Both period_left and event->count are carefully recalculated for auto > > reload. > > How does prev_count make sense when we've already reloaded a bunch of > times? We can figure it out how often there was a reload based on the PEBS index. -Andi
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On Tue, Dec 19, 2017 at 11:07:09PM +0100, Peter Zijlstra wrote: > On Tue, Dec 19, 2017 at 03:08:58PM -0500, Liang, Kan wrote: > > > This all looks very wrong... In auto reload we should never call > > > intel_pmu_save_and_restore() in the first place I think. > > > > > > Things like x86_perf_event_update() and x86_perf_event_set_period() > > > simply _cannot_ do the right thing when we auto reload the counter. > > > > > > > I think it should be OK to call it in first place. > > For x86_perf_event_update(), the reload_times will tell if it's auto reload. > > Both period_left and event->count are carefully recalculated for auto > > reload. > > How does prev_count make sense when we've already reloaded a bunch of > times? We can figure it out how often there was a reload based on the PEBS index. -Andi
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On Tue, Dec 19, 2017 at 03:08:58PM -0500, Liang, Kan wrote: > > This all looks very wrong... In auto reload we should never call > > intel_pmu_save_and_restore() in the first place I think. > > > > Things like x86_perf_event_update() and x86_perf_event_set_period() > > simply _cannot_ do the right thing when we auto reload the counter. > > > > I think it should be OK to call it in first place. > For x86_perf_event_update(), the reload_times will tell if it's auto reload. > Both period_left and event->count are carefully recalculated for auto > reload. How does prev_count make sense when we've already reloaded a bunch of times? > For x86_perf_event_set_period(), there is nothing special needed for auto > reload. The period is fixed. The period_left from x86_perf_event_update() is > already handled. Hurm.. I see. But rather than make an ever bigger trainwreck of things, I'd rather you just write a special purpose intel_pmu_save_and_restart() just for AUTO_RELOAD.
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On Tue, Dec 19, 2017 at 03:08:58PM -0500, Liang, Kan wrote: > > This all looks very wrong... In auto reload we should never call > > intel_pmu_save_and_restore() in the first place I think. > > > > Things like x86_perf_event_update() and x86_perf_event_set_period() > > simply _cannot_ do the right thing when we auto reload the counter. > > > > I think it should be OK to call it in first place. > For x86_perf_event_update(), the reload_times will tell if it's auto reload. > Both period_left and event->count are carefully recalculated for auto > reload. How does prev_count make sense when we've already reloaded a bunch of times? > For x86_perf_event_set_period(), there is nothing special needed for auto > reload. The period is fixed. The period_left from x86_perf_event_update() is > already handled. Hurm.. I see. But rather than make an ever bigger trainwreck of things, I'd rather you just write a special purpose intel_pmu_save_and_restart() just for AUTO_RELOAD.
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On 12/19/2017 3:08 PM, Liang, Kan wrote: On 12/19/2017 1:58 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote: arch/x86/events/core.c | 14 ++ arch/x86/events/intel/ds.c | 8 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 35552ea..f74e21d 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -100,6 +100,20 @@ u64 x86_perf_event_update(struct perf_event *event, * of the count. */ delta = (new_raw_count << shift) - (prev_raw_count << shift); + + /* + * Take auto-reload into account + * For the auto-reload before the last time, it went through the + * whole period (reload_val) every time. + * Just simply add period * times to the event. + * + * For the last load, the elapsed delta (event-)time need to be + * corrected by adding the period. Because the start point is -period. + */ + if (reload_times > 0) { + delta += (reload_val << shift); + local64_add(reload_val * (reload_times - 1), >count); + } delta >>= shift; local64_add(delta, >count); diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 0b693b7..f0f6026 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1256,11 +1256,17 @@ static void __intel_pmu_pebs_event(struct perf_event *event, void *base, void *top, int bit, int count) { + struct hw_perf_event *hwc = >hw; struct perf_sample_data data; struct pt_regs regs; void *at = get_next_pebs_record_by_bit(base, top, bit); - if (!intel_pmu_save_and_restart(event, 0, 0) && + /* + * Now, auto-reload is only enabled in fixed period mode. + * The reload value is always hwc->sample_period. + * May need to change it, if auto-reload is enabled in freq mode later. + */ + if (!intel_pmu_save_and_restart(event, hwc->sample_period, count - 1) && !(event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD)) return; This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period() simply _cannot_ do the right thing when we auto reload the counter. I think it should be OK to call it in first place. For x86_perf_event_update(), the reload_times will tell if it's auto reload. Both period_left and event->count are carefully recalculated for auto reload. Think a bit more. You are right. We cannot rely on count to tell us if it's auto reload. The count could also be 1 if auto reload is enabled. I will fix it in V2. Thanks, Kan For x86_perf_event_set_period(), there is nothing special needed for auto reload. The period is fixed. The period_left from x86_perf_event_update() is already handled. BTW: It should be 'count' not 'count - 1' which pass to intel_pmu_save_and_restart(). I just found the issue. I will fix it in V2 with other improvements if there are any. Thanks, Kan
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On 12/19/2017 3:08 PM, Liang, Kan wrote: On 12/19/2017 1:58 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote: arch/x86/events/core.c | 14 ++ arch/x86/events/intel/ds.c | 8 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 35552ea..f74e21d 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -100,6 +100,20 @@ u64 x86_perf_event_update(struct perf_event *event, * of the count. */ delta = (new_raw_count << shift) - (prev_raw_count << shift); + + /* + * Take auto-reload into account + * For the auto-reload before the last time, it went through the + * whole period (reload_val) every time. + * Just simply add period * times to the event. + * + * For the last load, the elapsed delta (event-)time need to be + * corrected by adding the period. Because the start point is -period. + */ + if (reload_times > 0) { + delta += (reload_val << shift); + local64_add(reload_val * (reload_times - 1), >count); + } delta >>= shift; local64_add(delta, >count); diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 0b693b7..f0f6026 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1256,11 +1256,17 @@ static void __intel_pmu_pebs_event(struct perf_event *event, void *base, void *top, int bit, int count) { + struct hw_perf_event *hwc = >hw; struct perf_sample_data data; struct pt_regs regs; void *at = get_next_pebs_record_by_bit(base, top, bit); - if (!intel_pmu_save_and_restart(event, 0, 0) && + /* + * Now, auto-reload is only enabled in fixed period mode. + * The reload value is always hwc->sample_period. + * May need to change it, if auto-reload is enabled in freq mode later. + */ + if (!intel_pmu_save_and_restart(event, hwc->sample_period, count - 1) && !(event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD)) return; This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period() simply _cannot_ do the right thing when we auto reload the counter. I think it should be OK to call it in first place. For x86_perf_event_update(), the reload_times will tell if it's auto reload. Both period_left and event->count are carefully recalculated for auto reload. Think a bit more. You are right. We cannot rely on count to tell us if it's auto reload. The count could also be 1 if auto reload is enabled. I will fix it in V2. Thanks, Kan For x86_perf_event_set_period(), there is nothing special needed for auto reload. The period is fixed. The period_left from x86_perf_event_update() is already handled. BTW: It should be 'count' not 'count - 1' which pass to intel_pmu_save_and_restart(). I just found the issue. I will fix it in V2 with other improvements if there are any. Thanks, Kan
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On 12/19/2017 1:58 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote: arch/x86/events/core.c | 14 ++ arch/x86/events/intel/ds.c | 8 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 35552ea..f74e21d 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -100,6 +100,20 @@ u64 x86_perf_event_update(struct perf_event *event, * of the count. */ delta = (new_raw_count << shift) - (prev_raw_count << shift); + + /* +* Take auto-reload into account +* For the auto-reload before the last time, it went through the +* whole period (reload_val) every time. +* Just simply add period * times to the event. +* +* For the last load, the elapsed delta (event-)time need to be +* corrected by adding the period. Because the start point is -period. +*/ + if (reload_times > 0) { + delta += (reload_val << shift); + local64_add(reload_val * (reload_times - 1), >count); + } delta >>= shift; local64_add(delta, >count); diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 0b693b7..f0f6026 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1256,11 +1256,17 @@ static void __intel_pmu_pebs_event(struct perf_event *event, void *base, void *top, int bit, int count) { + struct hw_perf_event *hwc = >hw; struct perf_sample_data data; struct pt_regs regs; void *at = get_next_pebs_record_by_bit(base, top, bit); - if (!intel_pmu_save_and_restart(event, 0, 0) && + /* +* Now, auto-reload is only enabled in fixed period mode. +* The reload value is always hwc->sample_period. +* May need to change it, if auto-reload is enabled in freq mode later. +*/ + if (!intel_pmu_save_and_restart(event, hwc->sample_period, count - 1) && !(event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD)) return; This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period() simply _cannot_ do the right thing when we auto reload the counter. I think it should be OK to call it in first place. For x86_perf_event_update(), the reload_times will tell if it's auto reload. Both period_left and event->count are carefully recalculated for auto reload. For x86_perf_event_set_period(), there is nothing special needed for auto reload. The period is fixed. The period_left from x86_perf_event_update() is already handled. BTW: It should be 'count' not 'count - 1' which pass to intel_pmu_save_and_restart(). I just found the issue. I will fix it in V2 with other improvements if there are any. Thanks, Kan
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On 12/19/2017 1:58 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote: arch/x86/events/core.c | 14 ++ arch/x86/events/intel/ds.c | 8 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 35552ea..f74e21d 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -100,6 +100,20 @@ u64 x86_perf_event_update(struct perf_event *event, * of the count. */ delta = (new_raw_count << shift) - (prev_raw_count << shift); + + /* +* Take auto-reload into account +* For the auto-reload before the last time, it went through the +* whole period (reload_val) every time. +* Just simply add period * times to the event. +* +* For the last load, the elapsed delta (event-)time need to be +* corrected by adding the period. Because the start point is -period. +*/ + if (reload_times > 0) { + delta += (reload_val << shift); + local64_add(reload_val * (reload_times - 1), >count); + } delta >>= shift; local64_add(delta, >count); diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 0b693b7..f0f6026 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1256,11 +1256,17 @@ static void __intel_pmu_pebs_event(struct perf_event *event, void *base, void *top, int bit, int count) { + struct hw_perf_event *hwc = >hw; struct perf_sample_data data; struct pt_regs regs; void *at = get_next_pebs_record_by_bit(base, top, bit); - if (!intel_pmu_save_and_restart(event, 0, 0) && + /* +* Now, auto-reload is only enabled in fixed period mode. +* The reload value is always hwc->sample_period. +* May need to change it, if auto-reload is enabled in freq mode later. +*/ + if (!intel_pmu_save_and_restart(event, hwc->sample_period, count - 1) && !(event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD)) return; This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period() simply _cannot_ do the right thing when we auto reload the counter. I think it should be OK to call it in first place. For x86_perf_event_update(), the reload_times will tell if it's auto reload. Both period_left and event->count are carefully recalculated for auto reload. For x86_perf_event_set_period(), there is nothing special needed for auto reload. The period is fixed. The period_left from x86_perf_event_update() is already handled. BTW: It should be 'count' not 'count - 1' which pass to intel_pmu_save_and_restart(). I just found the issue. I will fix it in V2 with other improvements if there are any. Thanks, Kan
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote: > arch/x86/events/core.c | 14 ++ > arch/x86/events/intel/ds.c | 8 +++- > 2 files changed, 21 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c > index 35552ea..f74e21d 100644 > --- a/arch/x86/events/core.c > +++ b/arch/x86/events/core.c > @@ -100,6 +100,20 @@ u64 x86_perf_event_update(struct perf_event *event, >* of the count. >*/ > delta = (new_raw_count << shift) - (prev_raw_count << shift); > + > + /* > + * Take auto-reload into account > + * For the auto-reload before the last time, it went through the > + * whole period (reload_val) every time. > + * Just simply add period * times to the event. > + * > + * For the last load, the elapsed delta (event-)time need to be > + * corrected by adding the period. Because the start point is -period. > + */ > + if (reload_times > 0) { > + delta += (reload_val << shift); > + local64_add(reload_val * (reload_times - 1), >count); > + } > delta >>= shift; > > local64_add(delta, >count); > diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c > index 0b693b7..f0f6026 100644 > --- a/arch/x86/events/intel/ds.c > +++ b/arch/x86/events/intel/ds.c > @@ -1256,11 +1256,17 @@ static void __intel_pmu_pebs_event(struct perf_event > *event, > void *base, void *top, > int bit, int count) > { > + struct hw_perf_event *hwc = >hw; > struct perf_sample_data data; > struct pt_regs regs; > void *at = get_next_pebs_record_by_bit(base, top, bit); > > - if (!intel_pmu_save_and_restart(event, 0, 0) && > + /* > + * Now, auto-reload is only enabled in fixed period mode. > + * The reload value is always hwc->sample_period. > + * May need to change it, if auto-reload is enabled in freq mode later. > + */ > + if (!intel_pmu_save_and_restart(event, hwc->sample_period, count - 1) && > !(event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD)) > return; > This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period() simply _cannot_ do the right thing when we auto reload the counter.
Re: [PATCH 2/4] perf/x86/intel: fix event update for auto-reload
On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote: > arch/x86/events/core.c | 14 ++ > arch/x86/events/intel/ds.c | 8 +++- > 2 files changed, 21 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c > index 35552ea..f74e21d 100644 > --- a/arch/x86/events/core.c > +++ b/arch/x86/events/core.c > @@ -100,6 +100,20 @@ u64 x86_perf_event_update(struct perf_event *event, >* of the count. >*/ > delta = (new_raw_count << shift) - (prev_raw_count << shift); > + > + /* > + * Take auto-reload into account > + * For the auto-reload before the last time, it went through the > + * whole period (reload_val) every time. > + * Just simply add period * times to the event. > + * > + * For the last load, the elapsed delta (event-)time need to be > + * corrected by adding the period. Because the start point is -period. > + */ > + if (reload_times > 0) { > + delta += (reload_val << shift); > + local64_add(reload_val * (reload_times - 1), >count); > + } > delta >>= shift; > > local64_add(delta, >count); > diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c > index 0b693b7..f0f6026 100644 > --- a/arch/x86/events/intel/ds.c > +++ b/arch/x86/events/intel/ds.c > @@ -1256,11 +1256,17 @@ static void __intel_pmu_pebs_event(struct perf_event > *event, > void *base, void *top, > int bit, int count) > { > + struct hw_perf_event *hwc = >hw; > struct perf_sample_data data; > struct pt_regs regs; > void *at = get_next_pebs_record_by_bit(base, top, bit); > > - if (!intel_pmu_save_and_restart(event, 0, 0) && > + /* > + * Now, auto-reload is only enabled in fixed period mode. > + * The reload value is always hwc->sample_period. > + * May need to change it, if auto-reload is enabled in freq mode later. > + */ > + if (!intel_pmu_save_and_restart(event, hwc->sample_period, count - 1) && > !(event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD)) > return; > This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period() simply _cannot_ do the right thing when we auto reload the counter.
[PATCH 2/4] perf/x86/intel: fix event update for auto-reload
From: Kan LiangThere is bug when mmap read event->count with large PEBS enabled. Here is an example. #./read_count 0x71f0 0x122c0 0x11c54 0x10001257d 0x2bdc5 There is auto-reload mechanism enabled for PEBS events in fixed period mode. But the calculation of event->count does not take the auto-reload values into account. Anyone who read the event->count will get wrong result, e.g x86_pmu_read. Also, the calculation of hwc->period_left is wrong either. It impacts the accuracy of period for the first record in PEBS multiple records. The issue is introduced with the auto-reload mechanism enabled by commit 851559e35fd5 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible") For the auto-reload before the last time, it went through the whole period (reload value) every time. So period * times should be added into the event->count. For the last load, the elapsed delta (event-)time need to be corrected by adding the period (reload value). Because the start point is -period. Signed-off-by: Kan Liang --- arch/x86/events/core.c | 14 ++ arch/x86/events/intel/ds.c | 8 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 35552ea..f74e21d 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -100,6 +100,20 @@ u64 x86_perf_event_update(struct perf_event *event, * of the count. */ delta = (new_raw_count << shift) - (prev_raw_count << shift); + + /* +* Take auto-reload into account +* For the auto-reload before the last time, it went through the +* whole period (reload_val) every time. +* Just simply add period * times to the event. +* +* For the last load, the elapsed delta (event-)time need to be +* corrected by adding the period. Because the start point is -period. +*/ + if (reload_times > 0) { + delta += (reload_val << shift); + local64_add(reload_val * (reload_times - 1), >count); + } delta >>= shift; local64_add(delta, >count); diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 0b693b7..f0f6026 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1256,11 +1256,17 @@ static void __intel_pmu_pebs_event(struct perf_event *event, void *base, void *top, int bit, int count) { + struct hw_perf_event *hwc = >hw; struct perf_sample_data data; struct pt_regs regs; void *at = get_next_pebs_record_by_bit(base, top, bit); - if (!intel_pmu_save_and_restart(event, 0, 0) && + /* +* Now, auto-reload is only enabled in fixed period mode. +* The reload value is always hwc->sample_period. +* May need to change it, if auto-reload is enabled in freq mode later. +*/ + if (!intel_pmu_save_and_restart(event, hwc->sample_period, count - 1) && !(event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD)) return; -- 2.7.4
[PATCH 2/4] perf/x86/intel: fix event update for auto-reload
From: Kan Liang There is bug when mmap read event->count with large PEBS enabled. Here is an example. #./read_count 0x71f0 0x122c0 0x11c54 0x10001257d 0x2bdc5 There is auto-reload mechanism enabled for PEBS events in fixed period mode. But the calculation of event->count does not take the auto-reload values into account. Anyone who read the event->count will get wrong result, e.g x86_pmu_read. Also, the calculation of hwc->period_left is wrong either. It impacts the accuracy of period for the first record in PEBS multiple records. The issue is introduced with the auto-reload mechanism enabled by commit 851559e35fd5 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible") For the auto-reload before the last time, it went through the whole period (reload value) every time. So period * times should be added into the event->count. For the last load, the elapsed delta (event-)time need to be corrected by adding the period (reload value). Because the start point is -period. Signed-off-by: Kan Liang --- arch/x86/events/core.c | 14 ++ arch/x86/events/intel/ds.c | 8 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 35552ea..f74e21d 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -100,6 +100,20 @@ u64 x86_perf_event_update(struct perf_event *event, * of the count. */ delta = (new_raw_count << shift) - (prev_raw_count << shift); + + /* +* Take auto-reload into account +* For the auto-reload before the last time, it went through the +* whole period (reload_val) every time. +* Just simply add period * times to the event. +* +* For the last load, the elapsed delta (event-)time need to be +* corrected by adding the period. Because the start point is -period. +*/ + if (reload_times > 0) { + delta += (reload_val << shift); + local64_add(reload_val * (reload_times - 1), >count); + } delta >>= shift; local64_add(delta, >count); diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 0b693b7..f0f6026 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1256,11 +1256,17 @@ static void __intel_pmu_pebs_event(struct perf_event *event, void *base, void *top, int bit, int count) { + struct hw_perf_event *hwc = >hw; struct perf_sample_data data; struct pt_regs regs; void *at = get_next_pebs_record_by_bit(base, top, bit); - if (!intel_pmu_save_and_restart(event, 0, 0) && + /* +* Now, auto-reload is only enabled in fixed period mode. +* The reload value is always hwc->sample_period. +* May need to change it, if auto-reload is enabled in freq mode later. +*/ + if (!intel_pmu_save_and_restart(event, hwc->sample_period, count - 1) && !(event->hw.flags & PERF_X86_EVENT_AUTO_RELOAD)) return; -- 2.7.4