Lines Matching refs: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
181 reason or if it does not recognize the processor). The name of the ``CPUIdle``
201 tick, but it is the primary reason for using it.
204 because it triggers periodically and relatively often (depending on the kernel
206 Thus, if the tick is allowed to trigger on idle CPUs, it will not make sense
212 Fortunately, it is not really necessary to allow the tick to trigger on idle
217 tick goes away if the given CPU is idle. Consequently, it is possible to stop
221 Whether or not it makes sense to stop the scheduler tick in the idle loop
226 wakeup within the tick range, stopping the tick is not necessary and it may even
237 tick range, it is better to allow the tick trigger. Otherwise, however, the
239 so that it does not wake up the CPU too early.
241 In any case, the governor knows what it is expecting and the decision on whether
242 or not to stop the scheduler tick belongs to it. Still, if the tick has been
243 stopped already (in one of the previous iterations of the loop), it is better
244 to leave it as is and the governor needs to take that into account.
247 loop altogether. That can be done through the build-time configuration of it
249 ``nohz=off`` to it in the command line. In both cases, as the stopping of the
250 scheduler tick is disabled, the governor's decisions regarding it are simply
256 which the tick cannot be stopped. If the given system is tickless, it will use
257 the ``menu`` governor by default and if it is not tickless, the default
258 ``CPUIdle`` governor on it will be ``ladder``.
269 the CPU will ask the processor hardware to enter), it attempts to predict the
288 to 1 the correction factor becomes (it must fall between 0 and 1 inclusive).
289 The sleep length is multiplied by the correction factor for the range that it
293 idle duration prediction. Namely, it saves the last 8 observed idle duration
294 values and, when predicting the idle duration next time, it computes the average
296 milliseconds) or it is small relative to the average (the average is greater
312 entering it will be relatively small, so likely it is better to avoid the
313 overhead related to entering that state and exiting it. Thus selecting a
324 them. For this purpose, it compares the target residency of each state with
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
332 happens if the idle duration predicted by it is less than the tick period and
335 the real time until the closest timer event and if it really is greater than
347 <menu-gov_>`_: it always tries to find the deepest idle state suitable for the
348 given conditions. However, it applies a different approach to that problem.
365 of it <idle-loop_>`_, must reflect the properties of the idle state at the
379 the module (including the time needed to enter it), because that is the minimum
414 deeper the (effective) idle state represented by it. Each of them contains
416 object corresponding to it, as follows:
464 description may be longer and it may contain white space or special characters.
467 The :file:`disable` attribute is the only writeable one. If it contains 1, the
469 governor will never select it for this particular CPU and the ``CPUIdle``
470 driver will never ask the hardware to enter it for that CPU as a result.
471 However, disabling an idle state for one CPU does not prevent it from being
472 asked for by the other CPUs, so it must be disabled for all of them in order to
478 this particular CPU, but it still may be disabled for some or all of the other
479 CPUs in the system at the same time. Writing 1 to it causes the idle state to
480 be disabled for this particular CPU and writing 0 to it allows the governor to
481 take it into consideration for the given CPU and the driver to ask for it,
482 unless that state was disabled globally in the driver (in which case it cannot
487 hierarchy of units in the processor, and it generally is hard to obtain idle
489 available) and if it contains a nonzero number, that number may not be very
490 accurate and it should not be relied on for anything meaningful.
493 really spent by the given CPU in the given idle state, because it is measured by
494 the kernel and it may not cover the cases in which the hardware refused to enter
495 this idle state and entered a shallower one instead of it (or even it did not
498 and it cannot say what really happened in the meantime at the hardware level.
504 it is to use idle state residency counters in the hardware, if available.
528 signed 32-bit integer) to it. In turn, the resume latency constraint for a CPU
537 as it may be less restrictive (greater in this particular case) than another
548 number written to it will be associated with the PM QoS request represented by
549 it as a new requested limit value. Next, the priority list mechanism will be
553 affected by it, which is the case if it is the minimum of the requested values
558 associated with that file descriptor, but it controls this particular PM QoS
562 file descriptor obtained while opening it, causes the PM QoS request associated
570 :file:`/sys/devices/system/cpu/cpu<N>/` in ``sysfs`` and writing to it causes
573 user space, so access to the file associated with it needs to be arbitrated
575 practice is to pin a process to the CPU in question and let it use the
576 ``sysfs`` interface to control the resume latency constraint for it.] It is
598 running on idle CPUs, but it prevents the CPU idle time governors and drivers
599 from being invoked. If it is added to the kernel command line, the idle loop
604 however, so it is rather crude and not very energy-efficient. For this reason,
605 it is not recommended for production use.
623 architecture support code to deal with idle CPUs. How it does that depends on
631 CPUs from saving almost any energy at all may not be the only effect of it.
632 For example, on Intel hardware it effectively prevents CPUs from using
634 idle, so it very well may hurt single-thread computations performance as well as
635 energy-efficiency. Thus using it for performance reasons may not be a good idea
639 ``acpi_idle`` to be used (as long as all of the information needed by it is
640 there in the system's ACPI tables), but it is not allowed to use the
658 can be loaded separately and ``max_cstate=<n>`` can be passed to it as a module
659 parameter when it is loaded.]