admin-guide/pm/cpuidle.rst

118 calls into a code module referred to as the *governor* that belongs to the CPU
122 processor hardware to enter the idle state selected by the governor.
124 The role of the governor is to find an idle state most suitable for the
134 taken into account by the governor, the *target residency* and the (worst-case)
147 There are two types of information that can influence the governor's decisions.
148 First of all, the governor knows the time until the closest timer event.  That
154 when that may happen.  The governor can only see how much time the CPU actually
158 governor uses that information depends on what algorithm is implemented by it
159 and that is the primary reason for having more than one governor in the
166 governors can be read from the :file:`available_governors`, and the governor
167 can be changed at runtime.  The name of the ``CPUIdle`` governor currently
222 depends on what is expected by the governor.  First, if there is another
225 reprogrammed in that case.  Second, if the governor is expecting a non-timer
227 be harmful.  Namely, in that case the governor will select an idle state with
229 going to be relatively shallow.  The governor really cannot select a deep idle
235 in the shallow idle state selected by the governor, which will be a waste of
236 energy.  Hence, if the governor is expecting a wakeup of any kind within the
238 governor will select a relatively deep idle state, so the tick should be stopped
241 In any case, the governor knows what it is expecting and the decision on whether
244 to leave it as is and the governor needs to take that into account.
250 scheduler tick is disabled, the governor's decisions regarding it are simply
257 the ``menu`` governor by default and if it is not tickless, the default
258 ``CPUIdle`` governor on it will be ``ladder``.
266 The ``menu`` governor is the default ``CPUIdle`` governor for tickless systems.
278 The ``menu`` governor maintains two arrays of sleep length correction factors.
292 Next, the governor uses a simple pattern recognition algorithm to refine its
308 Then, the governor computes an extra latency limit to help "interactive"
323 Now, the governor is ready to walk the list of idle states and choose one of
330 In the final step the governor may still need to refine the idle state selection
336 that time, the governor may need to select a shallower state with a suitable
345 The timer events oriented (TEO) governor is an alternative ``CPUIdle`` governor
395 used by the governor for idle state selection (for instance, the actual exit
397 idle state object selected by the governor).
469 governor will never select it for this particular CPU and the ``CPUIdle``
474 governor is implemented, disabling an idle state prevents that governor from
480 be disabled for this particular CPU and writing 0 to it allows the governor to
607 The ``cpuidle.governor=`` kernel command line switch allows the ``CPUIdle``
608 governor to use to be specified.  It has to be appended with a string matching
609 the name of an available governor (e.g. ``cpuidle.governor=menu``) and that
610 governor will be used instead of the default one.  It is possible to force
611 the ``menu`` governor to be used on the systems that use the ``ladder`` governor
655 for any of those idle states or expose them to the governor.  [The behavior of