Lines Matching +full:very +full:- +full:high
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
20 mess. The timers.c code is very "tightly coded" around jiffies and
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
25 code is very good and tight code, there's zero problems with it in its
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
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