admin-guide/pm/cpuidle.rst

58 to put the whole larger unit into an idle state which also will affect the
95 tasks assigned to it, the CPU will load the given task's context and run its
98 simultaneously, they will be subject to prioritization and time sharing in order
108 available idle states from being used, the CPU will simply execute more or less
140 latency, in turn, is the maximum time it will take a CPU asking the processor
150 when they will trigger, and it is the maximum time the hardware that the given
155 was idle after it has been woken up (that time will be referred to as the *idle
180 the ``acpi_idle`` driver will be used if ``intel_idle`` is disabled for some
206 Thus, if the tick is allowed to trigger on idle CPUs, it will not make sense
209 will never exceed the tick period length and the energy used for entering and
210 exiting idle states due to the tick wakeups on idle CPUs will be wasted.
227 be harmful.  Namely, in that case the governor will select an idle state with
235 in the shallow idle state selected by the governor, which will be a waste of
238 governor will select a relatively deep idle state, so the tick should be stopped
256 which the tick cannot be stopped.  If the given system is tickless, it will use
258 ``CPUIdle`` governor on it will be ``ladder``.
269 the CPU will ask the processor hardware to enter), it attempts to predict the
293 the assumption that the scheduler tick will be stopped.  That time, referred to
366 (say "X") at the "core" level by one core will trigger the module to try to
379 will start to execute the first new instruction (assuming that both cores in the
380 module will always be ready to execute instructions as soon as the module
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.
528 will be rejected in both cases and, also in both cases, the written integer
529 number will be interpreted as a requested PM QoS constraint in microseconds.
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
546 that effective value will be set as a new CPU latency limit.  Thus requesting a
547 new limit value will only change the real limit if the effective "list" value is
560 mechanism will be used again, to determine the new effective value for the whole
561 list and that value will become the new limit.
595 will ask the hardware to enter idle states on idle CPUs via the CPU architecture
605 governor will be used instead of the default one.  It is possible to force
620 ``idle=halt`` case, the architecture support code will use the ``HLT``
623 for this purpose, and if ``idle=poll`` is used, idle CPUs will execute a
635 driver will use the ``HLT`` instruction instead of ``MWAIT``. On systems
638 case, ``acpi_idle`` driver will function only if all the information needed
649 idle states deeper than idle state ``<n>``.  In that case, they will never ask