Messages in this thread | | | Subject | Re: [PATCH 04/10] tile: convert to use clocksource_register_hz | From | Peter Zijlstra <> | Date | Thu, 11 Nov 2010 23:22:13 +0100 |
| |
On Thu, 2010-11-11 at 14:06 -0800, john stultz wrote: > 1) How often is sched_clock guaranteed to be called? Once each tick, (so > the maximum time in nohz mode would be reasonable?)
Never,.. sparc64 for example can stay in nohz mode for hours. We have a nohz_exit hook for the kernel/sched_clock.c code though which resyncs us against the GTOD.
> 2) What considerations for sched_clock wrapping is there in generic > code? I see some considerations in kernel/sched_clock.c, but its not > obvious the limits. On x86, the 64-bit TSC won't wrap (but might jump on > non-synced systems, or halt in idle modes). Do architectures that have > faster-wrapping counters need to handle the cycle accumulation > internally?
Basically all code assumes we wrap on the u64 boundary.
So the whole kernel/sched_clock.c machinery tries to make a crummy arch sched_clock() usable, it syncs against the GTOD code (on tick, idle_exit and nohz_exit) and only assumes the arch sched_clock() wraps at the u64 boundary, jumps, inter-cpu drift etc are all taken care of.
| |