Lines Matching +full:one +full:- +full:timer +full:- +full:only

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
38 entity which appears to be fetching instructions that belong to one sequence
42 First, if the whole processor can only follow one sequence of instructions (one
46 Second, if the processor is multi-core, each core in it is able to follow at
47 least one program at a time.  The cores need not be entirely independent of each
49 work physically in parallel with each other, so if each of them executes only
50 one program, those programs run mostly independently of each other at the same
56 except for one have been put into idle states at the "core level" and the
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
70 by one of them, the hardware thread (or CPU) that asked for it is stopped, but
78 ---------
94 assigns it to one of the available CPUs to run and if there are no more runnable
96 code (from the instruction following the last one executed so far, possibly by
97 another CPU).  [If there are multiple runnable tasks assigned to one CPU
104 code may cause the processor to be put into one of its idle states, if they are
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)
137 substantial), in order to save more energy than it would save by entering one of
148 First of all, the governor knows the time until the closest timer event.  That
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
154 when that may happen.  The governor can only see how much time the CPU actually
157 time until the closest timer to estimate the idle duration in future.  How the
159 and that is the primary reason for having more than one governor in the
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
173 platform the kernel is running on, but there are platforms with more than one
175 majority of Intel platforms, ``intel_idle`` and ``acpi_idle``, one with
179 decision on which one of them to use has to be made early (on Intel platforms
186 .. _idle-cpus-and-tick:
191 The scheduler tick is a timer that triggers periodically in order to implement
193 multiple runnable tasks assigned to one CPU at the same time, the only way to
200 is there to make the switch happen regardless.  That is not the only role of the
214 "idle" one.  In other words, from the CPU scheduler perspective, the only user
223 (non-tick) timer due to trigger within the tick range, stopping the tick clearly
224 would be a waste of time, even though the timer hardware may not need to be
225 reprogrammed in that case.  Second, if the governor is expecting a non-timer
232 waste of time and in this case the timer hardware would need to be reprogrammed,
243 stopped already (in one of the previous iterations of the loop), it is better
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:
272 It first obtains the time until the closest timer event with the assumption
279 One of them is used when tasks previously running on the given CPU are waiting
280 for some I/O operations to complete and the other one is used when that is not
283 array is approximately 10 times wider than the previous one.
319 from the power management quality of service, or `PM QoS <cpu-pm-qos_>`_,
323 Now, the governor is ready to walk the list of idle states and choose one of
331 if it has not decided to `stop the scheduler tick <idle-cpus-and-tick_>`_.  That
335 the real time until the closest timer event and if it really is greater than
340 .. _teo-gov:
342 The Timer Events Oriented (TEO) Governor
345 The timer events oriented (TEO) governor is an alternative ``CPUIdle`` governor
346 for tickless systems.  It follows the same basic strategy as the ``menu`` `one
347 <menu-gov_>`_: it always tries to find the deepest idle state suitable for the
357 it avoids taking timer wakeups into account.  It also only uses idle duration
358 values less than the current time till the closest timer (with the scheduler
361 Like in the ``menu`` governor `case <menu-gov_>`_, the first step is to obtain
362 the *sleep length*, which is the time until the closest timer event with the
369 state will "match" the observed (post-wakeup) idle duration if it "matches" the
380 increased when the given idle state "matches" the sleep length only and 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)
389 deeper than the given one).
392 and finds the last (deepest) one with the target residency less than or equal
394 state are compared with each other and it is preselected if the ``hits`` one is
396 duration after CPU wakeup).  If the ``misses`` one is greater, the governor
401 <cpu-pm-qos_>`_ which is hit before reaching the deepest idle state with the
412 one and finds the deepest of them with the target residency within that average.
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
421 reflect the real time until the closest timer event and if it really is greater
426 .. _idle-states-representation:
432 supported by the processor have to be represented as a one-dimensional array of
435 is a hierarchy of units in the processor, one |struct cpuidle_state| object can
438 of it <idle-loop_>`_, must reflect the properties of the idle state at the
444 (say "X") at the "core" level by one core will trigger the module to try to
477 :c:type:`struct cpuidle_state_usage <cpuidle_state_usage>` one containing usage
485 objects defined for the given CPU minus one.  Each of these directories
486 corresponds to one idle state object and the larger the number in its name, the
540 The :file:`disable` attribute is the only writeable one.  If it contains 1, the
544 However, disabling an idle state for one CPU does not prevent it from being
548 selecting any idle states deeper than the disabled one too.]
568 this idle state and entered a shallower one instead of it (or even it did not
569 enter any idle state at all).  The kernel can only measure the time span between
575 particular case.  For these reasons, the only reliable way to find out how
585 .. _cpu-pm-qos:
592 energy-efficiency features of the kernel to prevent performance from dropping
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
625 new limit value will only change the real limit if the effective "list" value is
632 request only.
641 In turn, for each CPU there is one resume latency PM QoS request associated with
647 to avoid confusion.  [Arguably, the only legitimate use of this mechanism in
650 still only a request, however.  It is an entry in a priority list used to
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,
683 governor will be used instead of the default one.  It is possible to force
688 described below are only relevant for the *x86* architecture and references
689 to ``intel_idle`` affect Intel processors only.
704 CPUs from saving almost any energy at all may not be the only effect of it.
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 case, ``acpi_idle`` driver will function only if all the information needed
719 In addition to the architecture-level kernel command line options affecting CPU
725 `Representation of Idle States <idle-states-representation_>`_), causes the