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