no_hz.rst 15 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324
  1. ======================================
  2. NO_HZ: Reducing Scheduling-Clock Ticks
  3. ======================================
  4. This document describes Kconfig options and boot parameters that can
  5. reduce the number of scheduling-clock interrupts, thereby improving energy
  6. efficiency and reducing OS jitter. Reducing OS jitter is important for
  7. some types of computationally intensive high-performance computing (HPC)
  8. applications and for real-time applications.
  9. There are three main ways of managing scheduling-clock interrupts
  10. (also known as "scheduling-clock ticks" or simply "ticks"):
  11. 1. Never omit scheduling-clock ticks (CONFIG_HZ_PERIODIC=y or
  12. CONFIG_NO_HZ=n for older kernels). You normally will -not-
  13. want to choose this option.
  14. 2. Omit scheduling-clock ticks on idle CPUs (CONFIG_NO_HZ_IDLE=y or
  15. CONFIG_NO_HZ=y for older kernels). This is the most common
  16. approach, and should be the default.
  17. 3. Omit scheduling-clock ticks on CPUs that are either idle or that
  18. have only one runnable task (CONFIG_NO_HZ_FULL=y). Unless you
  19. are running realtime applications or certain types of HPC
  20. workloads, you will normally -not- want this option.
  21. These three cases are described in the following three sections, followed
  22. by a third section on RCU-specific considerations, a fourth section
  23. discussing testing, and a fifth and final section listing known issues.
  24. Never Omit Scheduling-Clock Ticks
  25. =================================
  26. Very old versions of Linux from the 1990s and the very early 2000s
  27. are incapable of omitting scheduling-clock ticks. It turns out that
  28. there are some situations where this old-school approach is still the
  29. right approach, for example, in heavy workloads with lots of tasks
  30. that use short bursts of CPU, where there are very frequent idle
  31. periods, but where these idle periods are also quite short (tens or
  32. hundreds of microseconds). For these types of workloads, scheduling
  33. clock interrupts will normally be delivered any way because there
  34. will frequently be multiple runnable tasks per CPU. In these cases,
  35. attempting to turn off the scheduling clock interrupt will have no effect
  36. other than increasing the overhead of switching to and from idle and
  37. transitioning between user and kernel execution.
  38. This mode of operation can be selected using CONFIG_HZ_PERIODIC=y (or
  39. CONFIG_NO_HZ=n for older kernels).
  40. However, if you are instead running a light workload with long idle
  41. periods, failing to omit scheduling-clock interrupts will result in
  42. excessive power consumption. This is especially bad on battery-powered
  43. devices, where it results in extremely short battery lifetimes. If you
  44. are running light workloads, you should therefore read the following
  45. section.
  46. In addition, if you are running either a real-time workload or an HPC
  47. workload with short iterations, the scheduling-clock interrupts can
  48. degrade your applications performance. If this describes your workload,
  49. you should read the following two sections.
  50. Omit Scheduling-Clock Ticks For Idle CPUs
  51. =========================================
  52. If a CPU is idle, there is little point in sending it a scheduling-clock
  53. interrupt. After all, the primary purpose of a scheduling-clock interrupt
  54. is to force a busy CPU to shift its attention among multiple duties,
  55. and an idle CPU has no duties to shift its attention among.
  56. The CONFIG_NO_HZ_IDLE=y Kconfig option causes the kernel to avoid sending
  57. scheduling-clock interrupts to idle CPUs, which is critically important
  58. both to battery-powered devices and to highly virtualized mainframes.
  59. A battery-powered device running a CONFIG_HZ_PERIODIC=y kernel would
  60. drain its battery very quickly, easily 2-3 times as fast as would the
  61. same device running a CONFIG_NO_HZ_IDLE=y kernel. A mainframe running
  62. 1,500 OS instances might find that half of its CPU time was consumed by
  63. unnecessary scheduling-clock interrupts. In these situations, there
  64. is strong motivation to avoid sending scheduling-clock interrupts to
  65. idle CPUs. That said, dyntick-idle mode is not free:
  66. 1. It increases the number of instructions executed on the path
  67. to and from the idle loop.
  68. 2. On many architectures, dyntick-idle mode also increases the
  69. number of expensive clock-reprogramming operations.
  70. Therefore, systems with aggressive real-time response constraints often
  71. run CONFIG_HZ_PERIODIC=y kernels (or CONFIG_NO_HZ=n for older kernels)
  72. in order to avoid degrading from-idle transition latencies.
  73. An idle CPU that is not receiving scheduling-clock interrupts is said to
  74. be "dyntick-idle", "in dyntick-idle mode", "in nohz mode", or "running
  75. tickless". The remainder of this document will use "dyntick-idle mode".
  76. There is also a boot parameter "nohz=" that can be used to disable
  77. dyntick-idle mode in CONFIG_NO_HZ_IDLE=y kernels by specifying "nohz=off".
  78. By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling
  79. dyntick-idle mode.
  80. Omit Scheduling-Clock Ticks For CPUs With Only One Runnable Task
  81. ================================================================
  82. If a CPU has only one runnable task, there is little point in sending it
  83. a scheduling-clock interrupt because there is no other task to switch to.
  84. Note that omitting scheduling-clock ticks for CPUs with only one runnable
  85. task implies also omitting them for idle CPUs.
  86. The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid
  87. sending scheduling-clock interrupts to CPUs with a single runnable task,
  88. and such CPUs are said to be "adaptive-ticks CPUs". This is important
  89. for applications with aggressive real-time response constraints because
  90. it allows them to improve their worst-case response times by the maximum
  91. duration of a scheduling-clock interrupt. It is also important for
  92. computationally intensive short-iteration workloads: If any CPU is
  93. delayed during a given iteration, all the other CPUs will be forced to
  94. wait idle while the delayed CPU finishes. Thus, the delay is multiplied
  95. by one less than the number of CPUs. In these situations, there is
  96. again strong motivation to avoid sending scheduling-clock interrupts.
  97. By default, no CPU will be an adaptive-ticks CPU. The "nohz_full="
  98. boot parameter specifies the adaptive-ticks CPUs. For example,
  99. "nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks
  100. CPUs. Note that you are prohibited from marking all of the CPUs as
  101. adaptive-tick CPUs: At least one non-adaptive-tick CPU must remain
  102. online to handle timekeeping tasks in order to ensure that system
  103. calls like gettimeofday() returns accurate values on adaptive-tick CPUs.
  104. (This is not an issue for CONFIG_NO_HZ_IDLE=y because there are no running
  105. user processes to observe slight drifts in clock rate.) Therefore, the
  106. boot CPU is prohibited from entering adaptive-ticks mode. Specifying a
  107. "nohz_full=" mask that includes the boot CPU will result in a boot-time
  108. error message, and the boot CPU will be removed from the mask. Note that
  109. this means that your system must have at least two CPUs in order for
  110. CONFIG_NO_HZ_FULL=y to do anything for you.
  111. Finally, adaptive-ticks CPUs must have their RCU callbacks offloaded.
  112. This is covered in the "RCU IMPLICATIONS" section below.
  113. Normally, a CPU remains in adaptive-ticks mode as long as possible.
  114. In particular, transitioning to kernel mode does not automatically change
  115. the mode. Instead, the CPU will exit adaptive-ticks mode only if needed,
  116. for example, if that CPU enqueues an RCU callback.
  117. Just as with dyntick-idle mode, the benefits of adaptive-tick mode do
  118. not come for free:
  119. 1. CONFIG_NO_HZ_FULL selects CONFIG_NO_HZ_COMMON, so you cannot run
  120. adaptive ticks without also running dyntick idle. This dependency
  121. extends down into the implementation, so that all of the costs
  122. of CONFIG_NO_HZ_IDLE are also incurred by CONFIG_NO_HZ_FULL.
  123. 2. The user/kernel transitions are slightly more expensive due
  124. to the need to inform kernel subsystems (such as RCU) about
  125. the change in mode.
  126. 3. POSIX CPU timers prevent CPUs from entering adaptive-tick mode.
  127. Real-time applications needing to take actions based on CPU time
  128. consumption need to use other means of doing so.
  129. 4. If there are more perf events pending than the hardware can
  130. accommodate, they are normally round-robined so as to collect
  131. all of them over time. Adaptive-tick mode may prevent this
  132. round-robining from happening. This will likely be fixed by
  133. preventing CPUs with large numbers of perf events pending from
  134. entering adaptive-tick mode.
  135. 5. Scheduler statistics for adaptive-tick CPUs may be computed
  136. slightly differently than those for non-adaptive-tick CPUs.
  137. This might in turn perturb load-balancing of real-time tasks.
  138. Although improvements are expected over time, adaptive ticks is quite
  139. useful for many types of real-time and compute-intensive applications.
  140. However, the drawbacks listed above mean that adaptive ticks should not
  141. (yet) be enabled by default.
  142. RCU Implications
  143. ================
  144. There are situations in which idle CPUs cannot be permitted to
  145. enter either dyntick-idle mode or adaptive-tick mode, the most
  146. common being when that CPU has RCU callbacks pending.
  147. The CONFIG_RCU_FAST_NO_HZ=y Kconfig option may be used to cause such CPUs
  148. to enter dyntick-idle mode or adaptive-tick mode anyway. In this case,
  149. a timer will awaken these CPUs every four jiffies in order to ensure
  150. that the RCU callbacks are processed in a timely fashion.
  151. Another approach is to offload RCU callback processing to "rcuo" kthreads
  152. using the CONFIG_RCU_NOCB_CPU=y Kconfig option. The specific CPUs to
  153. offload may be selected using The "rcu_nocbs=" kernel boot parameter,
  154. which takes a comma-separated list of CPUs and CPU ranges, for example,
  155. "1,3-5" selects CPUs 1, 3, 4, and 5.
  156. The offloaded CPUs will never queue RCU callbacks, and therefore RCU
  157. never prevents offloaded CPUs from entering either dyntick-idle mode
  158. or adaptive-tick mode. That said, note that it is up to userspace to
  159. pin the "rcuo" kthreads to specific CPUs if desired. Otherwise, the
  160. scheduler will decide where to run them, which might or might not be
  161. where you want them to run.
  162. Testing
  163. =======
  164. So you enable all the OS-jitter features described in this document,
  165. but do not see any change in your workload's behavior. Is this because
  166. your workload isn't affected that much by OS jitter, or is it because
  167. something else is in the way? This section helps answer this question
  168. by providing a simple OS-jitter test suite, which is available on branch
  169. master of the following git archive:
  170. git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git
  171. Clone this archive and follow the instructions in the README file.
  172. This test procedure will produce a trace that will allow you to evaluate
  173. whether or not you have succeeded in removing OS jitter from your system.
  174. If this trace shows that you have removed OS jitter as much as is
  175. possible, then you can conclude that your workload is not all that
  176. sensitive to OS jitter.
  177. Note: this test requires that your system have at least two CPUs.
  178. We do not currently have a good way to remove OS jitter from single-CPU
  179. systems.
  180. Known Issues
  181. ============
  182. * Dyntick-idle slows transitions to and from idle slightly.
  183. In practice, this has not been a problem except for the most
  184. aggressive real-time workloads, which have the option of disabling
  185. dyntick-idle mode, an option that most of them take. However,
  186. some workloads will no doubt want to use adaptive ticks to
  187. eliminate scheduling-clock interrupt latencies. Here are some
  188. options for these workloads:
  189. a. Use PMQOS from userspace to inform the kernel of your
  190. latency requirements (preferred).
  191. b. On x86 systems, use the "idle=mwait" boot parameter.
  192. c. On x86 systems, use the "intel_idle.max_cstate=" to limit
  193. ` the maximum C-state depth.
  194. d. On x86 systems, use the "idle=poll" boot parameter.
  195. However, please note that use of this parameter can cause
  196. your CPU to overheat, which may cause thermal throttling
  197. to degrade your latencies -- and that this degradation can
  198. be even worse than that of dyntick-idle. Furthermore,
  199. this parameter effectively disables Turbo Mode on Intel
  200. CPUs, which can significantly reduce maximum performance.
  201. * Adaptive-ticks slows user/kernel transitions slightly.
  202. This is not expected to be a problem for computationally intensive
  203. workloads, which have few such transitions. Careful benchmarking
  204. will be required to determine whether or not other workloads
  205. are significantly affected by this effect.
  206. * Adaptive-ticks does not do anything unless there is only one
  207. runnable task for a given CPU, even though there are a number
  208. of other situations where the scheduling-clock tick is not
  209. needed. To give but one example, consider a CPU that has one
  210. runnable high-priority SCHED_FIFO task and an arbitrary number
  211. of low-priority SCHED_OTHER tasks. In this case, the CPU is
  212. required to run the SCHED_FIFO task until it either blocks or
  213. some other higher-priority task awakens on (or is assigned to)
  214. this CPU, so there is no point in sending a scheduling-clock
  215. interrupt to this CPU. However, the current implementation
  216. nevertheless sends scheduling-clock interrupts to CPUs having a
  217. single runnable SCHED_FIFO task and multiple runnable SCHED_OTHER
  218. tasks, even though these interrupts are unnecessary.
  219. And even when there are multiple runnable tasks on a given CPU,
  220. there is little point in interrupting that CPU until the current
  221. running task's timeslice expires, which is almost always way
  222. longer than the time of the next scheduling-clock interrupt.
  223. Better handling of these sorts of situations is future work.
  224. * A reboot is required to reconfigure both adaptive idle and RCU
  225. callback offloading. Runtime reconfiguration could be provided
  226. if needed, however, due to the complexity of reconfiguring RCU at
  227. runtime, there would need to be an earthshakingly good reason.
  228. Especially given that you have the straightforward option of
  229. simply offloading RCU callbacks from all CPUs and pinning them
  230. where you want them whenever you want them pinned.
  231. * Additional configuration is required to deal with other sources
  232. of OS jitter, including interrupts and system-utility tasks
  233. and processes. This configuration normally involves binding
  234. interrupts and tasks to particular CPUs.
  235. * Some sources of OS jitter can currently be eliminated only by
  236. constraining the workload. For example, the only way to eliminate
  237. OS jitter due to global TLB shootdowns is to avoid the unmapping
  238. operations (such as kernel module unload operations) that
  239. result in these shootdowns. For another example, page faults
  240. and TLB misses can be reduced (and in some cases eliminated) by
  241. using huge pages and by constraining the amount of memory used
  242. by the application. Pre-faulting the working set can also be
  243. helpful, especially when combined with the mlock() and mlockall()
  244. system calls.
  245. * Unless all CPUs are idle, at least one CPU must keep the
  246. scheduling-clock interrupt going in order to support accurate
  247. timekeeping.
  248. * If there might potentially be some adaptive-ticks CPUs, there
  249. will be at least one CPU keeping the scheduling-clock interrupt
  250. going, even if all CPUs are otherwise idle.
  251. Better handling of this situation is ongoing work.
  252. * Some process-handling operations still require the occasional
  253. scheduling-clock tick. These operations include calculating CPU
  254. load, maintaining sched average, computing CFS entity vruntime,
  255. computing avenrun, and carrying out load balancing. They are
  256. currently accommodated by scheduling-clock tick every second
  257. or so. On-going work will eliminate the need even for these
  258. infrequent scheduling-clock ticks.