Lines Matching full:it
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
165 `stopped by the idle loop <idle-cpus-and-tick_>`_. It is possible to change the
167 been passed to the kernel, but that is not safe in general, so it should not be
183 reason or if it does not recognize the processor). The name of the ``CPUIdle``
203 tick, but it is the primary reason for using it.
206 because it triggers periodically and relatively often (depending on the kernel
208 Thus, if the tick is allowed to trigger on idle CPUs, it will not make sense
214 Fortunately, it is not really necessary to allow the tick to trigger on idle
219 tick goes away if the given CPU is idle. Consequently, it is possible to stop
223 Whether or not it makes sense to stop the scheduler tick in the idle loop
228 wakeup within the tick range, stopping the tick is not necessary and it may even
239 tick range, it is better to allow the tick trigger. Otherwise, however, the
241 so that it does not wake up the CPU too early.
243 In any case, the governor knows what it is expecting and the decision on whether
244 or not to stop the scheduler tick belongs to it. Still, if the tick has been
245 stopped already (in one of the previous iterations of the loop), it is better
246 to leave it as is and the governor needs to take that into account.
249 loop altogether. That can be done through the build-time configuration of it
251 ``nohz=off`` to it in the command line. In both cases, as the stopping of the
252 scheduler tick is disabled, the governor's decisions regarding it are simply
258 which the tick cannot be stopped. If the given system is tickless, it will use
259 the ``menu`` governor by default and if it is not tickless, the default
260 ``CPUIdle`` governor on it will be ``ladder``.
269 It is quite complex, but the basic principle of its design is straightforward.
271 the CPU will ask the processor hardware to enter), it attempts to predict the
274 It first obtains the time until the closest timer event with the assumption
277 wakeup. It is used to determine the sleep length range, which in turn is needed
290 to 1 the correction factor becomes (it must fall between 0 and 1 inclusive).
291 The sleep length is multiplied by the correction factor for the range that it
295 idle duration prediction. Namely, it saves the last 8 observed idle duration
296 values and, when predicting the idle duration next time, it computes the average
298 milliseconds) or it is small relative to the average (the average is greater
311 workloads. It uses the observation that if the exit latency of the selected
314 entering it will be relatively small, so likely it is better to avoid the
315 overhead related to entering that state and exiting it. Thus selecting a
326 them. For this purpose, it compares the target residency of each state with
327 the predicted idle duration and the exit latency of it with the computed latency
328 limit. It selects the state with the target residency closest to the predicted
329 idle duration, but still below it, and exit latency that does not exceed the
333 if it has not decided to `stop the scheduler tick <idle-cpus-and-tick_>`_. That
334 happens if the idle duration predicted by it is less than the tick period and
337 the real time until the closest timer event and if it really is greater than
348 for tickless systems. It follows the same basic strategy as the ``menu`` `one
349 <menu-gov_>`_: it always tries to find the deepest idle state suitable for the
350 given conditions. However, it applies a different approach to that problem.
352 First, it does not use sleep length correction factors, but instead it attempts
355 "match" the upcoming CPU idle interval. Second, it does not take the tasks
359 it avoids taking timer wakeups into account. It also only uses idle duration
371 state will "match" the observed (post-wakeup) idle duration if it "matches" the
380 (that is, it is increased when the given idle state "matches" both the sleep
386 "match" the observed (post-wakeup) idle duration if it does not "match" the
387 sleep length. It is subject to decay on every CPU wakeup and it is increased
388 when the idle state corresponding to it "matches" the observed (post-wakeup)
396 state are compared with each other and it is preselected if the ``hits`` one is
418 it has not decided to `stop the scheduler tick <idle-cpus-and-tick_>`_. That
423 reflect the real time until the closest timer event and if it really is greater
440 of it <idle-loop_>`_, must reflect the properties of the idle state at the
454 the module (including the time needed to enter it), because that is the minimum
489 deeper the (effective) idle state represented by it. Each of them contains
491 object corresponding to it, as follows:
532 description may be longer and it may contain white space or special characters.
535 The :file:`disable` attribute is the only writeable one. If it contains 1, the
537 governor will never select it for this particular CPU and the ``CPUIdle``
538 driver will never ask the hardware to enter it for that CPU as a result.
539 However, disabling an idle state for one CPU does not prevent it from being
540 asked for by the other CPUs, so it must be disabled for all of them in order to
546 this particular CPU, but it still may be disabled for some or all of the other
547 CPUs in the system at the same time. Writing 1 to it causes the idle state to
548 be disabled for this particular CPU and writing 0 to it allows the governor to
549 take it into consideration for the given CPU and the driver to ask for it,
550 unless that state was disabled globally in the driver (in which case it cannot
555 hierarchy of units in the processor, and it generally is hard to obtain idle
557 available) and if it contains a nonzero number, that number may not be very
558 accurate and it should not be relied on for anything meaningful.
561 really spent by the given CPU in the given idle state, because it is measured by
562 the kernel and it may not cover the cases in which the hardware refused to enter
563 this idle state and entered a shallower one instead of it (or even it did not
566 and it cannot say what really happened in the meantime at the hardware level.
572 it is to use idle state residency counters in the hardware, if available.
593 a binary value (interpreted as a signed 32-bit integer) to it. In turn, the
603 as it may be less restrictive (greater in this particular case) than another
613 used for writing, the number written to it will be associated with the PM QoS
614 request represented by it as a new requested constraint value. Next, the
618 real constraint if the effective "list" value is affected by it. In particular,
619 for the ``PM_QOS_CPU_DMA_LATENCY`` class it only affects the real constraint if
620 it is the minimum of the requested constraints in the list. The process holding
622 file controls the PM QoS request associated with that file descriptor, but it
626 file descriptor obtained while opening it, causes the PM QoS request associated
634 :file:`/sys/devices/system/cpu/cpu<N>/` in ``sysfs`` and writing to it causes
637 user space, so access to the file associated with it needs to be arbitrated
639 practice is to pin a process to the CPU in question and let it use the
640 ``sysfs`` interface to control the resume latency constraint for it.] It
641 still only is a request, however. It is a member of a priority list used to
661 CPU idle time management entirely. It does not prevent the idle loop from
662 running on idle CPUs, but it prevents the CPU idle time governors and drivers
663 from being invoked. If it is added to the kernel command line, the idle loop
668 however, so it is rather crude and not very energy-efficient. For this reason,
669 it is not recommended for production use.
672 governor to use to be specified. It has to be appended with a string matching
674 governor will be used instead of the default one. It is possible to force
687 architecture support code to deal with idle CPUs. How it does that depends on
695 CPUs from saving almost any energy at all may not be the only effect of it.
696 For example, on Intel hardware it effectively prevents CPUs from using
698 idle, so it very well may hurt single-thread computations performance as well as
699 energy-efficiency. Thus using it for performance reasons may not be a good idea
703 ``acpi_idle`` to be used (as long as all of the information needed by it is
704 there in the system's ACPI tables), but it is not allowed to use the
722 can be loaded separately and ``max_cstate=<n>`` can be passed to it as a module
723 parameter when it is loaded.]