Lines Matching +full:real +full:- +full:time
2 NO_HZ: Reducing Scheduling-Clock Ticks
7 reduce the number of scheduling-clock interrupts, thereby improving energy
9 some types of computationally intensive high-performance computing (HPC)
10 applications and for real-time applications.
12 There are three main ways of managing scheduling-clock interrupts
13 (also known as "scheduling-clock ticks" or simply "ticks"):
15 1. Never omit scheduling-clock ticks (CONFIG_HZ_PERIODIC=y or
16 CONFIG_NO_HZ=n for older kernels). You normally will -not-
19 2. Omit scheduling-clock ticks on idle CPUs (CONFIG_NO_HZ_IDLE=y or
23 3. Omit scheduling-clock ticks on CPUs that are either idle or that
26 workloads, you will normally -not- want this option.
29 by a third section on RCU-specific considerations, a fourth section
33 Never Omit Scheduling-Clock Ticks
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
53 periods, failing to omit scheduling-clock interrupts will result in
54 excessive power consumption. This is especially bad on battery-powered
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
65 Omit Scheduling-Clock Ticks For Idle CPUs
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
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".
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
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:
91 2. On many architectures, dyntick-idle mode also increases the
92 number of expensive clock-reprogramming operations.
94 Therefore, systems with aggressive real-time response constraints often
96 in order to avoid degrading from-idle transition latencies.
99 dyntick-idle mode in CONFIG_NO_HZ_IDLE=y kernels by specifying "nohz=off".
101 dyntick-idle mode.
104 Omit Scheduling-Clock Ticks For CPUs With Only One Runnable Task
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
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
122 again strong motivation to avoid sending scheduling-clock interrupts.
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
128 adaptive-tick CPUs: At least one non-adaptive-tick CPU must remain
130 calls like gettimeofday() returns accurate values on adaptive-tick CPUs.
136 Finally, adaptive-ticks CPUs must have their RCU callbacks offloaded.
139 Normally, a CPU remains in adaptive-ticks mode as long as possible.
141 the mode. Instead, the CPU will exit adaptive-ticks mode only if needed,
144 Just as with dyntick-idle mode, the benefits of adaptive-tick mode do
156 3. POSIX CPU timers prevent CPUs from entering adaptive-tick mode.
157 Real-time applications needing to take actions based on CPU time
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
165 entering adaptive-tick mode.
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.
171 Although improvements are expected over time, adaptive ticks is quite
172 useful for many types of real-time and compute-intensive applications.
181 enter either dyntick-idle mode or adaptive-tick mode, the most
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
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
202 So you enable all the OS-jitter features described in this document,
206 by providing a simple OS-jitter test suite, which is available on branch
209 git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git
219 We do not currently have a good way to remove OS jitter from single-CPU
226 * Dyntick-idle slows transitions to and from idle slightly.
228 aggressive real-time workloads, which have the option of disabling
229 dyntick-idle mode, an option that most of them take. However,
231 eliminate scheduling-clock interrupt latencies. Here are some
240 ` the maximum C-state depth.
245 to degrade your latencies -- and that this degradation can
246 be even worse than that of dyntick-idle. Furthermore,
250 * Adaptive-ticks slows user/kernel transitions slightly.
256 * Adaptive-ticks does not do anything unless there is only one
258 of other situations where the scheduling-clock tick is not
260 runnable high-priority SCHED_FIFO task and an arbitrary number
261 of low-priority SCHED_OTHER tasks. In this case, the CPU is
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
266 nevertheless sends scheduling-clock interrupts to CPUs having a
273 longer than the time of the next scheduling-clock interrupt.
286 of OS jitter, including interrupts and system-utility tasks
297 by the application. Pre-faulting the working set can also be
302 scheduling-clock interrupt going in order to support accurate
305 * If there might potentially be some adaptive-ticks CPUs, there
306 will be at least one CPU keeping the scheduling-clock interrupt
311 * Some process-handling operations still require the occasional
312 scheduling-clock tick. These operations include calculating CPU
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.