Documentation/timers/timekeeping.rst

2 Clock sources, Clock events, sched_clock() and delay timers
10 If you grep through the kernel source you will find a number of architecture-
11 specific implementations of clock sources, clockevents and several likewise
12 architecture-specific overrides of the sched_clock() function and some
17 on this timeline, providing facilities such as high-resolution timers.
22 Clock sources
23 -------------
31 n bits which count from 0 to (2^n)-1 and then wraps around to 0 and start over.
36 shall be as stable and correct as possible as compared to a real-world wall
46 When the wall-clock accuracy of the clock source isn't satisfactory, there
48 the user-visible time to RTC clocks in the system or against networked time
70 For real simple clock sources accessed from a single I/O memory location
76 Since a 32-bit counter at say 100 MHz will wrap around to zero after some 43
79 member telling how many bits of the source are valid. This way the timekeeping
86 ------------
88 Clock events are the conceptual reverse of clock sources: they take a
92 Clock events are orthogonal to clock sources. The same hardware
109 -------------
111 In addition to the clock sources and clock events there is a special weak
123 Compared to clock sources, sched_clock() has to be very fast: it is called
124 much more often, especially by the scheduler. If you have to do trade-offs
143 The sched_clock() function should be callable in any context, IRQ- and
144 NMI-safe and return a sane value in any context.
146 Some architectures may have a limited set of time sources and lack a nice
147 counter to derive a 64-bit nanosecond value, so for example on the ARM
149 sched_clock() nanosecond base from a 16- or 32-bit counter. Sometimes the
161 --------------------------------------
174 Enter timer-based delays. Using these, a timer read may be used instead of
175 a hard-coded loop for providing the desired delay.