admin-guide/pm/cpuidle.rst

20 a program is suspended and instructions belonging to it are not fetched from
25 it is an opportunity to save energy.
39 (program) from memory and executing them, but it need not work this way
43 program) at a time, it is a CPU.  In that case, if the hardware is asked to
46 Second, if the processor is multi-core, each core in it is able to follow at
52 enter an idle state, that applies to the core that asked for it in the first
53 place, but it also may apply to a larger unit (say a "package" or a "cluster")
54 that the core belongs to (in fact, it may apply to an entire hierarchy of larger
57 remaining core asks the processor to enter an idle state, that may trigger it
70 by one of them, the hardware thread (or CPU) that asked for it is stopped, but
74 it may be put into an idle state as a whole (if the other cores within the
94 assigns it to one of the available CPUs to run and if there are no more runnable
95 tasks assigned to it, the CPU will load the given task's context and run its
109 useless instructions in a loop until it is assigned a new task to run.
117 The idle loop code takes two major steps in every iteration of it.  First, it
120 the CPU to ask the hardware to enter.  Second, it invokes another code module
136 spend in the given state, including the time needed to enter it (which may be
137 substantial), in order to save more energy than it would save by entering one of
140 latency, in turn, is the maximum time it will take a CPU asking the processor
144 hardware is entering it and it must be entered completely to be exited in an
149 time is known exactly, because the kernel programs timers and it knows exactly
150 when they will trigger, and it is the maximum time the hardware that the given
152 and exit it.  However, the CPU may be woken up by a non-timer event at any time
153 (in particular, before the closest timer triggers) and it generally is not known
155 was idle after it has been woken up (that time will be referred to as the *idle
156 duration* from now on) and it can use that information somehow along with the
158 governor uses that information depends on what algorithm is implemented by it
181 reason or if it does not recognize the processor).  The name of the ``CPUIdle``
201 tick, but it is the primary reason for using it.
204 because it triggers periodically and relatively often (depending on the kernel
206 Thus, if the tick is allowed to trigger on idle CPUs, it will not make sense
212 Fortunately, it is not really necessary to allow the tick to trigger on idle
217 tick goes away if the given CPU is idle.  Consequently, it is possible to stop
221 Whether or not it makes sense to stop the scheduler tick in the idle loop
226 wakeup within the tick range, stopping the tick is not necessary and it may even
237 tick range, it is better to allow the tick trigger.  Otherwise, however, the
239 so that it does not wake up the CPU too early.
241 In any case, the governor knows what it is expecting and the decision on whether
242 or not to stop the scheduler tick belongs to it.  Still, if the tick has been
243 stopped already (in one of the previous iterations of the loop), it is better
244 to leave it as is and the governor needs to take that into account.
247 loop altogether.  That can be done through the build-time configuration of it
249 ``nohz=off`` to it in the command line.  In both cases, as the stopping of the
250 scheduler tick is disabled, the governor's decisions regarding it are simply
256 which the tick cannot be stopped.  If the given system is tickless, it will use
257 the ``menu`` governor by default and if it is not tickless, the default
258 ``CPUIdle`` governor on it will be ``ladder``.
267 It is quite complex, but the basic principle of its design is straightforward.
269 the CPU will ask the processor hardware to enter), it attempts to predict the
272 It first uses a simple pattern recognition algorithm to obtain a preliminary
273 idle duration prediction.  Namely, it saves the last 8 observed idle duration
274 values and, when predicting the idle duration next time, it computes the average
276 milliseconds) or it is small relative to the average (the average is greater
295 next CPU wakeup.  It is used to determine the sleep length range, which in turn
306 to 1 the correction factor becomes (it must fall between 0 and 1 inclusive).
307 The sleep length is multiplied by the correction factor for the range that it
313 to be woken up soon enough, the sleep length computation is skipped as it may
318 them.  For this purpose, it compares the target residency of each state with
319 the predicted idle duration and the exit latency of it with the with the latency
321 framework.  It selects the state with the target residency closest to the predicted
322 idle duration, but still below it, and exit latency that does not exceed the
326 if it has not decided to `stop the scheduler tick <idle-cpus-and-tick_>`_.  That
327 happens if the idle duration predicted by it is less than the tick period and
330 the real time until the closest timer event and if it really is greater than
341 for tickless systems.  It follows the same basic strategy as the ``menu`` `one
342 <menu-gov_>`_: it always tries to find the deepest idle state suitable for the
343 given conditions.  However, it applies a different approach to that problem.
360 of it <idle-loop_>`_, must reflect the properties of the idle state at the
374 the module (including the time needed to enter it), because that is the minimum
409 deeper the (effective) idle state represented by it.  Each of them contains
411 object corresponding to it, as follows:
459 description may be longer and it may contain white space or special characters.
462 The :file:`disable` attribute is the only writeable one.  If it contains 1, the
464 governor will never select it for this particular CPU and the ``CPUIdle``
465 driver will never ask the hardware to enter it for that CPU as a result.
466 However, disabling an idle state for one CPU does not prevent it from being
467 asked for by the other CPUs, so it must be disabled for all of them in order to
473 this particular CPU, but it still may be disabled for some or all of the other
474 CPUs in the system at the same time.  Writing 1 to it causes the idle state to
475 be disabled for this particular CPU and writing 0 to it allows the governor to
476 take it into consideration for the given CPU and the driver to ask for it,
477 unless that state was disabled globally in the driver (in which case it cannot
482 hierarchy of units in the processor, and it generally is hard to obtain idle
484 available) and if it contains a nonzero number, that number may not be very
485 accurate and it should not be relied on for anything meaningful.
488 really spent by the given CPU in the given idle state, because it is measured by
489 the kernel and it may not cover the cases in which the hardware refused to enter
490 this idle state and entered a shallower one instead of it (or even it did not
493 and it cannot say what really happened in the meantime at the hardware level.
499 it is to use idle state residency counters in the hardware, if available.
523 signed 32-bit integer) to it.  In turn, the resume latency constraint for a CPU
532 as it may be less restrictive (greater in this particular case) than another
543 number written to it will be associated with the PM QoS request represented by
544 it as a new requested limit value.  Next, the priority list mechanism will be
548 affected by it, which is the case if it is the minimum of the requested values
553 associated with that file descriptor, but it controls this particular PM QoS
557 file descriptor obtained while opening it, causes the PM QoS request associated
565 :file:`/sys/devices/system/cpu/cpu<N>/` in ``sysfs`` and writing to it causes
568 user space, so access to the file associated with it needs to be arbitrated
570 practice is to pin a process to the CPU in question and let it use the
571 ``sysfs`` interface to control the resume latency constraint for it.]  It is
572 still only a request, however.  It is an entry in a priority list used to
592 CPU idle time management entirely.  It does not prevent the idle loop from
593 running on idle CPUs, but it prevents the CPU idle time governors and drivers
594 from being invoked.  If it is added to the kernel command line, the idle loop
599 however, so it is rather crude and not very energy-efficient.  For this reason,
600 it is not recommended for production use.
603 governor to use to be specified.  It has to be appended with a string matching
605 governor will be used instead of the default one.  It is possible to force
618 architecture support code to deal with idle CPUs.  How it does that depends on
626 CPUs from saving almost any energy at all may not be the only effect of it.
627 For example, on Intel hardware it effectively prevents CPUs from using
629 idle, so it very well may hurt single-thread computations performance as well as
630 energy-efficiency.  Thus using it for performance reasons may not be a good idea
639 by it is in the system's ACPI tables.
656 can be loaded separately and ``max_cstate=<n>`` can be passed to it as a module
657 parameter when it is loaded.]