Lines Matching refs:of

8 (kernel/timers.c), why do we need two timer subsystems? After a lot of
18 - the forced handling of low-resolution and high-resolution timers in
19   the same way leads to a lot of compromises, macro magic and #ifdef
29 - the unpredictable [O(N)] overhead of cascading leads to delays which
30   necessitate a more complex handling of high resolution timers, which
32   timing inaccuracies. Cascading is a fundamental property of the timer
34   degrading other portions of the timers.c code in an unacceptable way.
36 - the implementation of the current posix-timer subsystem on top of
37   the timer wheel has already introduced a quite complex handling of
38   the required readjusting of absolute CLOCK_REALTIME timers at
46   I/O. The vast majority of those timers never expire and are rarely
48   can be removed from the timer wheel before any further processing of
49   them becomes necessary. Thus the users of these timeouts can accept
50   the granularity and precision tradeoffs of the timer wheel, and
52   Accurate timing for them is not a core purpose - in fact most of the
54   evil to guarantee the processing of actual timeout completions
55   (because most of the timeouts are deleted before completion), which
58 The primary users of precision timers are user-space applications that
61 (e.g. multimedia) can benefit from the availability of a separate
72 special-purpose optimization of the existing timer wheel for the low
75 hrtimers. E.g. we could decrease the frequency of the timeout subsystem
88 - simplification of existing, timing related kernel code
90 another basic requirement was the immediate enqueueing and ordering of
94 used in various performance-critical areas of e.g. memory management and
103 Time-ordered enqueueing is not purely for the purposes of
104 high-resolution clocks though, it also simplifies the handling of
106 implementation needed to keep an extra list of all armed absolute
107 CLOCK_REALTIME timers along with complex locking. In case of
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
114 of posix-timers simpler in general.
116 The locking and per-CPU behavior of hrtimers was mostly taken from the
127 representation of ktime_t values and operations is implemented via
132 to avoid the performance impact of 64-bit multiplications and divisions
138 hrtimers - rounding of timer values
151 We used the high-resolution clock subsystem ontop of hrtimers to verify
163 The conversion of nanosleep and posix-timers enabled the unification of
176 code got a healthy amount of testing and use in practice.