[PATCH] nomadik: prevent sched_clock() wraparound
Nicolas Pitre
nico at fluxnic.net
Wed Nov 17 10:04:00 EST 2010
On Wed, 17 Nov 2010, Linus Walleij wrote:
> 2010/11/17 Linus Walleij <linus.ml.walleij at gmail.com>:
>
> > Hm! Then in this code in plat-orion/timer.c:
> >
> > #define TCLK2NS_SCALE_FACTOR 8
> > static unsigned long tclk2ns_scale;
> >
> > unsigned long long sched_clock(void)
> > {
> > unsigned long long v = cnt32_to_63(0xffffffff - readl(TIMER0_VAL));
> > return (v * tclk2ns_scale) >> TCLK2NS_SCALE_FACTOR;
> > }
>
> Looking at this again it seems the Orion is implicitly
> loosing bits - so this code will work and multiply out some of the
> 63 bits so it just wraps around earlier.
Exact. And that's what the comment above it says:
* Orion's sched_clock implementation. It has a resolution of
* at least 7.5ns (133MHz TCLK) and a maximum value of 834 days.
The 834 days comes from the fact that the final shift preserves only 56
bits from the result.
On PXA this is even worse:
* This is PXA's sched_clock implementation. This has a resolution
* of at least 308 ns and a maximum value of 208 days.
But again, in the context of sched_clock() this is fine. We want
sched_clock() to be fast, and having a glitch during that jiffy when the
clock wraps back every 208 days is perfectly reasonable.
> Would be nice to have these kind of things explicit though,
> it's a bit hard to determine when this counter will wrap.
It is all commented, at least in those implementations I've written
myself.
Nicolas
More information about the linux-arm-kernel
mailing list