Messages in this thread | | | Subject | Re: [PATCH] clocksource: document some basic concepts | From | Peter Zijlstra <> | Date | Mon, 15 Nov 2010 22:13:04 +0100 |
| |
On Mon, 2010-11-15 at 15:06 -0500, Nicolas Pitre wrote: > 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.
Right, its like sched_clock() would go backwards and we loose some precision during that jiffy (assuming the arch uses HAVE_UNSTABLE_SCHED_CLOCK), nothing too horrible.
> > 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.
Whatever works, dealing with the wrap is only a few shifts.
| |