admin-guide/pm/cpuidle.rst

1 .. SPDX-License-Identifier: GPL-2.0
27 CPU idle time management is an energy-efficiency feature concerned about using
31 ------------
37 software as individual single-core processors.  In other words, a CPU is an
46 Second, if the processor is multi-core, each core in it is able to follow at
61 Finally, each core in a multi-core processor may be able to follow more than one
66 multiple individual single-core "processors", referred to as *hardware threads*
67 (or hyper-threads specifically on Intel hardware), that each can follow one
78 ---------
107 next wakeup event, or there are strict latency constraints preventing any of the
112 .. _idle-loop:
127 the platform or the processor architecture and organized in a one-dimensional
134 taken into account by the governor, the *target residency* and the (worst-case)
135 *exit latency*.  The target residency is the minimum time the hardware must
139 corresponds to the power drawn by the processor in that state.]  The exit
140 latency, in turn, is the maximum time it will take a CPU asking the processor
142 wakeup from that state.  Note that in general the exit latency also must cover
152 and exit it.  However, the CPU may be woken up by a non-timer event at any time
162 There are four ``CPUIdle`` governors available, ``menu``, `TEO <teo-gov_>`_,
165 tick can be `stopped by the idle loop <idle-cpus-and-tick_>`_.  Available
186 .. _idle-cpus-and-tick:
223 (non-tick) timer due to trigger within the tick range, stopping the tick clearly
225 reprogrammed in that case.  Second, if the governor is expecting a non-timer
247 loop altogether.  That can be done through the build-time configuration of it
255 generally regarded as more energy-efficient than the systems running kernels in
261 .. _menu-gov:
308 Then, the governor computes an extra latency limit to help "interactive"
309 workloads.  It uses the observation that if the exit latency of the selected
315 of the extra latency limit is the predicted idle duration itself which
318 complete.  The result of that division is compared with the latency limit coming
319 from the power management quality of service, or `PM QoS <cpu-pm-qos_>`_,
321 exit latency.
325 the predicted idle duration and the exit latency of it with the computed latency
327 idle duration, but still below it, and exit latency that does not exceed the
331 if it has not decided to `stop the scheduler tick <idle-cpus-and-tick_>`_.  That
340 .. _teo-gov:
347 <menu-gov_>`_: it always tries to find the deepest idle state suitable for the
361 Like in the ``menu`` governor `case <menu-gov_>`_, the first step is to obtain
369 state will "match" the observed (post-wakeup) idle duration if it "matches" the
384 "match" the observed (post-wakeup) idle duration if it does not "match" the
386 when the idle state corresponding to it "matches" the observed (post-wakeup)
400 [If there is a wakeup latency constraint coming from the `PM QoS framework
401 <cpu-pm-qos_>`_ which is hit before reaching the deepest idle state with the
402 target residency within the sleep length, the deepest idle state with the exit
403 latency within the constraint is preselected without consulting the ``hits``,
416 it has not decided to `stop the scheduler tick <idle-cpus-and-tick_>`_.  That
420 `case <menu-gov_>`_, the sleep length used in the previous computations may not
426 .. _idle-states-representation:
432 supported by the processor have to be represented as a one-dimensional array of
437 the hierarchy.  In that case, the `target residency and exit latency parameters
438 of it <idle-loop_>`_, must reflect the properties of the idle state at the
454 that state.  Analogously, the exit latency parameter of that object must cover
455 the exit time of idle state "MX" of the module (and usually its entry time too),
468 used by the governor for idle state selection (for instance, the actual exit
469 latency of that idle state must not exceed the exit latency parameter of the
472 In addition to the target residency and exit latency idle state parameters
510 ``latency``
511 	Exit latency of the idle state in microseconds.
585 .. _cpu-pm-qos:
592 energy-efficiency features of the kernel to prevent performance from dropping
596 global CPU latency limit and through the resume latency constraints for
601 signed 32-bit integer) to it.  In turn, the resume latency constraint for a CPU
603 32-bit integer) to the :file:`power/pm_qos_resume_latency_us` file under
613 global CPU latency limit and for each individual CPU, aggregates them and
618 PM QoS request to be created and added to a global priority list of CPU latency
624 that effective value will be set as a new CPU latency limit.  Thus requesting a
637 latency limit requests and destroyed.  If that happens, the priority list
641 In turn, for each CPU there is one resume latency PM QoS request associated with
649 ``sysfs`` interface to control the resume latency constraint for it.]  It is
651 determine the effective value to be set as the resume latency constraint for the
656 (effective) CPU latency limit and the effective resume latency constraint for
657 the given CPU as the upper limit for the exit latency of the idle states that
659 states with exit latency beyond that limit.
666 `disabled for individual CPUs <idle-states-representation_>`_, there are kernel
677 however, so it is rather crude and not very energy-efficient.  For this reason,
706 P-states (see |cpufreq|) that require any number of CPUs in a package to be
707 idle, so it very well may hurt single-thread computations performance as well as
708 energy-efficiency.  Thus using it for performance reasons may not be a good idea
716 In addition to the architecture-level kernel command line options affecting CPU
722 `Representation of Idle States <idle-states-representation_>`_), causes the