Messages in this thread | | | Date | Mon, 15 Nov 2010 15:06:29 -0500 (EST) | From | Nicolas Pitre <> | Subject | Re: [PATCH] clocksource: document some basic concepts |
| |
On Mon, 15 Nov 2010, Peter Zijlstra wrote:
> On Mon, 2010-11-15 at 11:33 +0100, Linus Walleij wrote: > > +The sched_clock() function may wrap only on unsigned long long boundaries, > > +i.e. after 64 bits. Since this is a nanosecond value this will mean it wraps > > +after circa 585 years. (For most practical systems this means "never".)
This is not necessarily the case. Some implementations require a scaling factor too, making the number of remaining bits smaller than 64. See arch/arm/mach-pxa/time.c:sched_clock() for example, which has a maximum range of 208 days. Of course, in practice we don't really care if sched_clock() wraps each 208 days, unlike for clock-source.
> Currently true, John Stultz was going to look into ammending this by > teaching the kernel/sched_clock.c bits about early wraps (and a way for > architectures to specify this) > > #define SCHED_CLOCK_WRAP_BITS 48 > > ... > > #ifdef SCHED_CLOCK_WRAP_BITS > /* handle short wraps */ > #endif
Is this worth supporting? I'd simply use the low 32 bits and extend it to 63 bits using cnt32_to_63(). If the low 32 bits are wrapping too fast, then just shifting them down a few positions first should do the trick. That certainly would have a much faster result.
Nicolas
| |