hrtimers.rst 8.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178
  1. ======================================================
  2. hrtimers - subsystem for high-resolution kernel timers
  3. ======================================================
  4. This patch introduces a new subsystem for high-resolution kernel timers.
  5. One might ask the question: we already have a timer subsystem
  6. (kernel/timers.c), why do we need two timer subsystems? After a lot of
  7. back and forth trying to integrate high-resolution and high-precision
  8. features into the existing timer framework, and after testing various
  9. such high-resolution timer implementations in practice, we came to the
  10. conclusion that the timer wheel code is fundamentally not suitable for
  11. such an approach. We initially didn't believe this ('there must be a way
  12. to solve this'), and spent a considerable effort trying to integrate
  13. things into the timer wheel, but we failed. In hindsight, there are
  14. several reasons why such integration is hard/impossible:
  15. - the forced handling of low-resolution and high-resolution timers in
  16. the same way leads to a lot of compromises, macro magic and #ifdef
  17. mess. The timers.c code is very "tightly coded" around jiffies and
  18. 32-bitness assumptions, and has been honed and micro-optimized for a
  19. relatively narrow use case (jiffies in a relatively narrow HZ range)
  20. for many years - and thus even small extensions to it easily break
  21. the wheel concept, leading to even worse compromises. The timer wheel
  22. code is very good and tight code, there's zero problems with it in its
  23. current usage - but it is simply not suitable to be extended for
  24. high-res timers.
  25. - the unpredictable [O(N)] overhead of cascading leads to delays which
  26. necessitate a more complex handling of high resolution timers, which
  27. in turn decreases robustness. Such a design still leads to rather large
  28. timing inaccuracies. Cascading is a fundamental property of the timer
  29. wheel concept, it cannot be 'designed out' without inevitably
  30. degrading other portions of the timers.c code in an unacceptable way.
  31. - the implementation of the current posix-timer subsystem on top of
  32. the timer wheel has already introduced a quite complex handling of
  33. the required readjusting of absolute CLOCK_REALTIME timers at
  34. settimeofday or NTP time - further underlying our experience by
  35. example: that the timer wheel data structure is too rigid for high-res
  36. timers.
  37. - the timer wheel code is most optimal for use cases which can be
  38. identified as "timeouts". Such timeouts are usually set up to cover
  39. error conditions in various I/O paths, such as networking and block
  40. I/O. The vast majority of those timers never expire and are rarely
  41. recascaded because the expected correct event arrives in time so they
  42. can be removed from the timer wheel before any further processing of
  43. them becomes necessary. Thus the users of these timeouts can accept
  44. the granularity and precision tradeoffs of the timer wheel, and
  45. largely expect the timer subsystem to have near-zero overhead.
  46. Accurate timing for them is not a core purpose - in fact most of the
  47. timeout values used are ad-hoc. For them it is at most a necessary
  48. evil to guarantee the processing of actual timeout completions
  49. (because most of the timeouts are deleted before completion), which
  50. should thus be as cheap and unintrusive as possible.
  51. The primary users of precision timers are user-space applications that
  52. utilize nanosleep, posix-timers and itimer interfaces. Also, in-kernel
  53. users like drivers and subsystems which require precise timed events
  54. (e.g. multimedia) can benefit from the availability of a separate
  55. high-resolution timer subsystem as well.
  56. While this subsystem does not offer high-resolution clock sources just
  57. yet, the hrtimer subsystem can be easily extended with high-resolution
  58. clock capabilities, and patches for that exist and are maturing quickly.
  59. The increasing demand for realtime and multimedia applications along
  60. with other potential users for precise timers gives another reason to
  61. separate the "timeout" and "precise timer" subsystems.
  62. Another potential benefit is that such a separation allows even more
  63. special-purpose optimization of the existing timer wheel for the low
  64. resolution and low precision use cases - once the precision-sensitive
  65. APIs are separated from the timer wheel and are migrated over to
  66. hrtimers. E.g. we could decrease the frequency of the timeout subsystem
  67. from 250 Hz to 100 HZ (or even smaller).
  68. hrtimer subsystem implementation details
  69. ----------------------------------------
  70. the basic design considerations were:
  71. - simplicity
  72. - data structure not bound to jiffies or any other granularity. All the
  73. kernel logic works at 64-bit nanoseconds resolution - no compromises.
  74. - simplification of existing, timing related kernel code
  75. another basic requirement was the immediate enqueueing and ordering of
  76. timers at activation time. After looking at several possible solutions
  77. such as radix trees and hashes, we chose the red black tree as the basic
  78. data structure. Rbtrees are available as a library in the kernel and are
  79. used in various performance-critical areas of e.g. memory management and
  80. file systems. The rbtree is solely used for time sorted ordering, while
  81. a separate list is used to give the expiry code fast access to the
  82. queued timers, without having to walk the rbtree.
  83. (This separate list is also useful for later when we'll introduce
  84. high-resolution clocks, where we need separate pending and expired
  85. queues while keeping the time-order intact.)
  86. Time-ordered enqueueing is not purely for the purposes of
  87. high-resolution clocks though, it also simplifies the handling of
  88. absolute timers based on a low-resolution CLOCK_REALTIME. The existing
  89. implementation needed to keep an extra list of all armed absolute
  90. CLOCK_REALTIME timers along with complex locking. In case of
  91. settimeofday and NTP, all the timers (!) had to be dequeued, the
  92. time-changing code had to fix them up one by one, and all of them had to
  93. be enqueued again. The time-ordered enqueueing and the storage of the
  94. expiry time in absolute time units removes all this complex and poorly
  95. scaling code from the posix-timer implementation - the clock can simply
  96. be set without having to touch the rbtree. This also makes the handling
  97. of posix-timers simpler in general.
  98. The locking and per-CPU behavior of hrtimers was mostly taken from the
  99. existing timer wheel code, as it is mature and well suited. Sharing code
  100. was not really a win, due to the different data structures. Also, the
  101. hrtimer functions now have clearer behavior and clearer names - such as
  102. hrtimer_try_to_cancel() and hrtimer_cancel() [which are roughly
  103. equivalent to del_timer() and del_timer_sync()] - so there's no direct
  104. 1:1 mapping between them on the algorithmic level, and thus no real
  105. potential for code sharing either.
  106. Basic data types: every time value, absolute or relative, is in a
  107. special nanosecond-resolution type: ktime_t. The kernel-internal
  108. representation of ktime_t values and operations is implemented via
  109. macros and inline functions, and can be switched between a "hybrid
  110. union" type and a plain "scalar" 64bit nanoseconds representation (at
  111. compile time). The hybrid union type optimizes time conversions on 32bit
  112. CPUs. This build-time-selectable ktime_t storage format was implemented
  113. to avoid the performance impact of 64-bit multiplications and divisions
  114. on 32bit CPUs. Such operations are frequently necessary to convert
  115. between the storage formats provided by kernel and userspace interfaces
  116. and the internal time format. (See include/linux/ktime.h for further
  117. details.)
  118. hrtimers - rounding of timer values
  119. -----------------------------------
  120. the hrtimer code will round timer events to lower-resolution clocks
  121. because it has to. Otherwise it will do no artificial rounding at all.
  122. one question is, what resolution value should be returned to the user by
  123. the clock_getres() interface. This will return whatever real resolution
  124. a given clock has - be it low-res, high-res, or artificially-low-res.
  125. hrtimers - testing and verification
  126. -----------------------------------
  127. We used the high-resolution clock subsystem ontop of hrtimers to verify
  128. the hrtimer implementation details in praxis, and we also ran the posix
  129. timer tests in order to ensure specification compliance. We also ran
  130. tests on low-resolution clocks.
  131. The hrtimer patch converts the following kernel functionality to use
  132. hrtimers:
  133. - nanosleep
  134. - itimers
  135. - posix-timers
  136. The conversion of nanosleep and posix-timers enabled the unification of
  137. nanosleep and clock_nanosleep.
  138. The code was successfully compiled for the following platforms:
  139. i386, x86_64, ARM, PPC, PPC64, IA64
  140. The code was run-tested on the following platforms:
  141. i386(UP/SMP), x86_64(UP/SMP), ARM, PPC
  142. hrtimers were also integrated into the -rt tree, along with a
  143. hrtimers-based high-resolution clock implementation, so the hrtimers
  144. code got a healthy amount of testing and use in practice.
  145. Thomas Gleixner, Ingo Molnar