Lines Matching +full:high +full:- +full:precision
2 hrtimers - subsystem for high-resolution kernel timers
5 This patch introduces a new subsystem for high-resolution kernel timers.
9 back and forth trying to integrate high-resolution and high-precision
11 such high-resolution timer implementations in practice, we came to the
18 - the forced handling of low-resolution and high-resolution timers in
21 32-bitness assumptions, and has been honed and micro-optimized for a
23 for many years - and thus even small extensions to it easily break
26 current usage - but it is simply not suitable to be extended for
27 high-res timers.
29 - the unpredictable [O(N)] overhead of cascading leads to delays which
30 necessitate a more complex handling of high resolution timers, which
36 - the implementation of the current posix-timer subsystem on top of
39 settimeofday or NTP time - further underlying our experience by
40 example: that the timer wheel data structure is too rigid for high-res
43 - the timer wheel code is most optimal for use cases which can be
50 the granularity and precision tradeoffs of the timer wheel, and
51 largely expect the timer subsystem to have near-zero overhead.
52 Accurate timing for them is not a core purpose - in fact most of the
53 timeout values used are ad-hoc. For them it is at most a necessary
58 The primary users of precision timers are user-space applications that
59 utilize nanosleep, posix-timers and itimer interfaces. Also, in-kernel
62 high-resolution timer subsystem as well.
64 While this subsystem does not offer high-resolution clock sources just
65 yet, the hrtimer subsystem can be easily extended with high-resolution
72 special-purpose optimization of the existing timer wheel for the low
73 resolution and low precision use cases - once the precision-sensitive
79 ----------------------------------------
83 - simplicity
85 - data structure not bound to jiffies or any other granularity. All the
86 kernel logic works at 64-bit nanoseconds resolution - no compromises.
88 - simplification of existing, timing related kernel code
94 used in various performance-critical areas of e.g. memory management and
100 high-resolution clocks, where we need separate pending and expired
101 queues while keeping the time-order intact.)
103 Time-ordered enqueueing is not purely for the purposes of
104 high-resolution clocks though, it also simplifies the handling of
105 absolute timers based on a low-resolution CLOCK_REALTIME. The existing
109 time-changing code had to fix them up one by one, and all of them had to
110 be enqueued again. The time-ordered enqueueing and the storage of the
112 scaling code from the posix-timer implementation - the clock can simply
114 of posix-timers simpler in general.
116 The locking and per-CPU behavior of hrtimers was mostly taken from the
119 hrtimer functions now have clearer behavior and clearer names - such as
121 equivalent to timer_delete() and timer_delete_sync()] - so there's no direct
126 special nanosecond-resolution 64bit type: ktime_t.
127 (Originally, the kernel-internal representation of ktime_t values and
133 hrtimers - rounding of timer values
134 -----------------------------------
136 the hrtimer code will round timer events to lower-resolution clocks
141 a given clock has - be it low-res, high-res, or artificially-low-res.
143 hrtimers - testing and verification
144 -----------------------------------
146 We used the high-resolution clock subsystem on top of hrtimers to verify
149 tests on low-resolution clocks.
154 - nanosleep
155 - itimers
156 - posix-timers
158 The conversion of nanosleep and posix-timers enabled the unification of
165 The code was run-tested on the following platforms:
169 hrtimers were also integrated into the -rt tree, along with a
170 hrtimers-based high-resolution clock implementation, so the hrtimers