| Message ID | 1416412346-8759-1-git-send-email-daniel.thompson@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Wed, Nov 19, 2014 at 03:52:26PM +0000, Daniel Thompson wrote: > If the overflow threshold for a counter is set above or near the > 0xffffffff boundary then the kernel may lose track of the overflow > causing only events that occur *after* the overflow to be recorded. > Specifically the problem occurs when the value of the performance counter > overtakes its original programmed value due to wrap around. > > Typical solutions to this problem are either to avoid programming in > values likely to be overtaken or to treat the overflow bit as the 33rd > bit of the counter. > > Its somewhat fiddly to refactor the code to correctly handle the 33rd bit > during irqsave sections (context switches for example) so instead we take > the simpler approach of avoiding values likely to be overtaken. > > We set the limit to half of max_period because this matches the limit > imposed in __hw_perf_event_init(). This causes a doubling of the interrupt > rate for large threshold values, however even with a very fast counter > ticking at 4GHz the interrupt rate would only be ~1Hz. > > Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> > --- > > Notes: > There is similar code in the arm64 tree which retains the assumptions of > the original arm code regarding 32-bit wide performance counters. If > this patch doesn't get beaten up during review I'll also share a similar > patch for arm64. > > > arch/arm/kernel/perf_event.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c > index 266cba46db3e..b50a770f8c99 100644 > --- a/arch/arm/kernel/perf_event.c > +++ b/arch/arm/kernel/perf_event.c > @@ -115,8 +115,14 @@ int armpmu_event_set_period(struct perf_event *event) > ret = 1; > } > > - if (left > (s64)armpmu->max_period) > - left = armpmu->max_period; > + /* > + * Limit the maximum period to prevent the counter value > + * from overtaking the one we are about to program. In > + * effect we are reducing max_period to account for > + * interrupt latency (and we are being very conservative). > + */ > + if (left > (s64)(armpmu->max_period >> 1)) > + left = armpmu->max_period >> 1; The s64 cast looks off here, can we just drop it entirely? Will
On 19/11/14 18:11, Will Deacon wrote: > On Wed, Nov 19, 2014 at 03:52:26PM +0000, Daniel Thompson wrote: >> If the overflow threshold for a counter is set above or near the >> 0xffffffff boundary then the kernel may lose track of the overflow >> causing only events that occur *after* the overflow to be recorded. >> Specifically the problem occurs when the value of the performance counter >> overtakes its original programmed value due to wrap around. >> >> Typical solutions to this problem are either to avoid programming in >> values likely to be overtaken or to treat the overflow bit as the 33rd >> bit of the counter. >> >> Its somewhat fiddly to refactor the code to correctly handle the 33rd bit >> during irqsave sections (context switches for example) so instead we take >> the simpler approach of avoiding values likely to be overtaken. >> >> We set the limit to half of max_period because this matches the limit >> imposed in __hw_perf_event_init(). This causes a doubling of the interrupt >> rate for large threshold values, however even with a very fast counter >> ticking at 4GHz the interrupt rate would only be ~1Hz. >> >> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> >> --- >> >> Notes: >> There is similar code in the arm64 tree which retains the assumptions of >> the original arm code regarding 32-bit wide performance counters. If >> this patch doesn't get beaten up during review I'll also share a similar >> patch for arm64. >> >> >> arch/arm/kernel/perf_event.c | 10 ++++++++-- >> 1 file changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c >> index 266cba46db3e..b50a770f8c99 100644 >> --- a/arch/arm/kernel/perf_event.c >> +++ b/arch/arm/kernel/perf_event.c >> @@ -115,8 +115,14 @@ int armpmu_event_set_period(struct perf_event *event) >> ret = 1; >> } >> >> - if (left > (s64)armpmu->max_period) >> - left = armpmu->max_period; >> + /* >> + * Limit the maximum period to prevent the counter value >> + * from overtaking the one we are about to program. In >> + * effect we are reducing max_period to account for >> + * interrupt latency (and we are being very conservative). >> + */ >> + if (left > (s64)(armpmu->max_period >> 1)) >> + left = armpmu->max_period >> 1; > > The s64 cast looks off here, can we just drop it entirely? Yes. left will always be positive at this point in the code and therefore can be safely promoted within this expression (and generated no extra warnings for me). I'll change this (although I might just keep the redundant braces because > and >> are composed of the same characters making it hard to read without the braces).
This patchset fixes problems on arm and arm64 when the PMU counters wrap around and become larger than the value originally programmed into them. The problem was observed and fixed on arm but the perf code is, rather to my surprise, sufficiently similar on arm64 that the fix still makes sense there too. v2: * Remove the redundant cast to s64 (Will Deacon). Daniel Thompson (2): arm: perf: Prevent wraparound during overflow arm64: perf: Prevent wraparound during overflow arch/arm/kernel/perf_event.c | 10 ++++++++-- arch/arm64/kernel/perf_event.c | 10 ++++++++-- 2 files changed, 16 insertions(+), 4 deletions(-) -- 1.9.3
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c index 266cba46db3e..b50a770f8c99 100644 --- a/arch/arm/kernel/perf_event.c +++ b/arch/arm/kernel/perf_event.c @@ -115,8 +115,14 @@ int armpmu_event_set_period(struct perf_event *event) ret = 1; } - if (left > (s64)armpmu->max_period) - left = armpmu->max_period; + /* + * Limit the maximum period to prevent the counter value + * from overtaking the one we are about to program. In + * effect we are reducing max_period to account for + * interrupt latency (and we are being very conservative). + */ + if (left > (s64)(armpmu->max_period >> 1)) + left = armpmu->max_period >> 1; local64_set(&hwc->prev_count, (u64)-left);
If the overflow threshold for a counter is set above or near the 0xffffffff boundary then the kernel may lose track of the overflow causing only events that occur *after* the overflow to be recorded. Specifically the problem occurs when the value of the performance counter overtakes its original programmed value due to wrap around. Typical solutions to this problem are either to avoid programming in values likely to be overtaken or to treat the overflow bit as the 33rd bit of the counter. Its somewhat fiddly to refactor the code to correctly handle the 33rd bit during irqsave sections (context switches for example) so instead we take the simpler approach of avoiding values likely to be overtaken. We set the limit to half of max_period because this matches the limit imposed in __hw_perf_event_init(). This causes a doubling of the interrupt rate for large threshold values, however even with a very fast counter ticking at 4GHz the interrupt rate would only be ~1Hz. Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> --- Notes: There is similar code in the arm64 tree which retains the assumptions of the original arm code regarding 32-bit wide performance counters. If this patch doesn't get beaten up during review I'll also share a similar patch for arm64. arch/arm/kernel/perf_event.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) -- 1.9.3