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