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.
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
55 into a nanosecond value as an unsigned long long (unsigned 64 bit) number.
58 possible to a nanosecond value using only the arithmetic operations
66 mult factor from a fixed shift, and clocksource_register_hz() and
76 Since a 32-bit counter at say 100 MHz will wrap around to zero after some 43
86 ------------
89 desired time specification value and calculate the values to poke into
96 system, it is ideal (and customary) to have one such event driving timer per
109 -------------
124 much more often, especially by the scheduler. If you have to do trade-offs
130 i.e. after 64 bits. Since this is a nanosecond value this will mean it wraps
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 --------------------------------------
166 jiffy) value, calibrated on boot.
168 Let's hope that your system is running on maximum frequency when this value
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.