Documentation/timers/timekeeping.rst

10 If you grep through the kernel source you will find a number of architecture-
12 architecture-specific overrides of the sched_clock() function and some
17 on this timeline, providing facilities such as high-resolution timers.
23 -------------
31 n bits which count from 0 to (2^n)-1 and then wraps around to 0 and start over.
35 The clock source shall have as high resolution as possible, and the frequency
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
76 Since a 32-bit counter at say 100 MHz will wrap around to zero after some 43
86 ------------
109 -------------
124 much more often, especially by the scheduler. If you have to do trade-offs
125 between accuracy compared to the clock source, you may sacrifice accuracy
135 jiffy frequency for the architecture. This will affect scheduling accuracy
143 The sched_clock() function should be callable in any context, IRQ- and
144 NMI-safe and return a sane value in any context.
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.