Lines Matching +full:high +full:- +full:performance
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
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 del_timer() and del_timer_sync()] - so there's no direct
126 special nanosecond-resolution type: ktime_t. The kernel-internal
131 CPUs. This build-time-selectable ktime_t storage format was implemented
132 to avoid the performance impact of 64-bit multiplications and divisions
138 hrtimers - rounding of timer values
139 -----------------------------------
141 the hrtimer code will round timer events to lower-resolution clocks
146 a given clock has - be it low-res, high-res, or artificially-low-res.
148 hrtimers - testing and verification
149 -----------------------------------
151 We used the high-resolution clock subsystem ontop of hrtimers to verify
154 tests on low-resolution clocks.
159 - nanosleep
160 - itimers
161 - posix-timers
163 The conversion of nanosleep and posix-timers enabled the unification of
170 The code was run-tested on the following platforms:
174 hrtimers were also integrated into the -rt tree, along with a
175 hrtimers-based high-resolution clock implementation, so the hrtimers