The clock chip on 386/486, and TSC when available (Pentium and above). See
arch/i386/kernel/time.c, function do_gettimeoffset().
On Alpha, do_gettimeoffset() unfortunately isn't factored out, but in
fact, it's rpcc() - state.last_time multiplied with the ns per cycle.
On m68k, there's mach_gettimeoffset(), which certainly is machine specific
(Atari has a different timer than Amiga...), but since I wrote a 20 us
precision timer on the Atari, I know it's doable just as on the older PCs (and
simpler, since the prescaler isn't divided into two parts).
ARM provides gettimeoffset().
SPARC and SPARC64 provides microsecond gettimeofday with some ugly
assembly code by DaveM, unfortunately yet again not factored out into a
do_gettimeoffset.
PPC has a decrementer, which is disabled for SMP (obviously the
decrementers of the different CPUs aren't in sync, and the developer didn't throw in
the effort to work around that); not factored out in do_gettimeoffset,
either.
MIPS again has a do_gettimeoffset() function, which works similar to the
x86 version (slow and fast with something that corresponds the TSC).
I agree that without a TSC or something similar (decrementer on PPC,
roll-around-every-few-seconds tick count on Alpha, etc.), UTIME has the problem
of a slipping clock. Non-monotonic gettimeofday() is just lazyness of the
developer, you always can keep the last returned value and return the max of
both, even when your clock moves slightly backwards from time to time.
Slipping can be reduced by synchronizing with the RTC (or better use xntpd/ntpdate,
when possible).
If the UTIME patches misses to reschedule after an event, that's a bug. It
has to.
-- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/Sent through Global Message Exchange - http://www.gmx.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/