[PATCH] ARM: perf: ensure overflows aren't missed due to IRQ latency
Ashwin Chaugule
ashwinc at codeaurora.org
Wed Mar 23 14:35:22 EDT 2011
On 03/23/2011 02:28 PM, Jamie Iles wrote:
> Hmm, I'm not really sure I follow that and see how it works for an
> overflow when new < prev. Why doesn't the naive:
>
> new_raw_count &= armpmu->max_period;
> prev_raw_count &= armpmu->max_period;
> if (overflow)
> delta = (armpmu->max_period - prev_raw_count) +
> new_raw_count
> else
> delta = new_raw_count - prev_raw_count;
>
> work? I'm sure I'm missing something here!
>
> Jamie
When new < prev, delta will be greater than 2^32. So we'll have accounted for the overflow condition anyway.
The naive solution you mention above is what we discussed earlier and works too.
I guess the additional:
> new_raw_count &= armpmu->max_period;
> prev_raw_count &= armpmu->max_period;
just makes it cleaner than the shifting to upper 32bits, subtracting and then shifting back again.
Cheers,
Ashwin
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
More information about the linux-arm-kernel
mailing list