Lines Matching +full:very +full:- +full:high

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
43 potentially being updated in between leading to the risk of very strange
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
56 Since this operation may be invoked very often, doing this in a strict
76 Since a 32-bit counter at say 100 MHz will wrap around to zero after some 43
86 ------------
109 -------------
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.
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.