[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