Lines Matching refs:timer

7 One might ask the question: we already have a timer subsystem
8 (kernel/timers.c), why do we need two timer subsystems? After a lot of
10 features into the existing timer framework, and after testing various
11 such high-resolution timer implementations in practice, we came to the
12 conclusion that the timer wheel code is fundamentally not suitable for
15 things into the timer wheel, but we failed. In hindsight, there are
24   the wheel concept, leading to even worse compromises. The timer wheel
32   timing inaccuracies. Cascading is a fundamental property of the timer
36 - the implementation of the current posix-timer subsystem on top of
37   the timer wheel has already introduced a quite complex handling of
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
48   can be removed from the timer wheel before any further processing of
50   the granularity and precision tradeoffs of the timer wheel, and
51   largely expect the timer subsystem to have near-zero overhead.
62 high-resolution timer subsystem as well.
69 separate the "timeout" and "precise timer" subsystems.
72 special-purpose optimization of the existing timer wheel for the low
74 APIs are separated from the timer wheel and are migrated over to
112 scaling code from the posix-timer implementation - the clock can simply
117 existing timer wheel code, as it is mature and well suited. Sharing code
133 hrtimers - rounding of timer values
136 the hrtimer code will round timer events to lower-resolution clocks
148 timer tests in order to ensure specification compliance. We also ran