Lines Matching full:time

8 CPU Idle Time Management
27 CPU idle time management is an energy-efficiency feature concerned about using
33 CPU idle time management operates on CPUs as seen by the *CPU scheduler* (that
43 program) at a time, it is a CPU.  In that case, if the hardware is asked to
47 least one program at a time.  The cores need not be entirely independent of each
48 other (for example, they may share caches), but still most of the time they
51 time.  The entire cores are CPUs in that case and if the hardware is asked to
62 program in the same time frame (that is, each core may be able to fetch
63 instructions from multiple locations in memory and execute them in the same time
69 time management perspective and if the processor is asked to enter an idle state
87 processor every time the task's code is run by a CPU.  The CPU scheduler
98 simultaneously, they will be subject to prioritization and time sharing in order
99 to allow them to make some progress over time.]
106 idle states, or there is not enough time to spend in an idle state before the
119 idle time management subsystem called ``CPUIdle`` to select an idle state for
130 time.  This allows ``CPUIdle`` governors to be independent of the underlying
135 *exit latency*.  The target residency is the minimum time the hardware must
136 spend in the given state, including the time needed to enter it (which may be
140 latency, in turn, is the maximum time it will take a CPU asking the processor
143 the time needed to enter the given state in case the wakeup occurs when the
148 First of all, the governor knows the time until the closest timer event.  That
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
151 CPU depends on can spend in an idle state, including the time necessary to enter
152 and exit it.  However, the CPU may be woken up by a non-timer event at any time
154 when that may happen.  The governor can only see how much time the CPU actually
155 was idle after it has been woken up (that time will be referred to as the *idle
157 time until the closest timer to estimate the idle duration in future.  How the
178 driver chosen at the system initialization time cannot be replaced later, so the
192 the time sharing strategy of the CPU scheduler.  Of course, if there are
193 multiple runnable tasks assigned to one CPU at the same time, the only way to
194 allow them to make reasonable progress in a given time frame is to make them
195 share the available CPU time.  Namely, in rough approximation, each task is
196 given a slice of the CPU time to run its code, subject to the scheduling class,
197 prioritization and so on and when that time slice is used up, the CPU should be
203 The scheduler tick is problematic from the CPU idle time management perspective,
215 of the CPU time on them is the idle loop.  Since the time of an idle CPU need
224 would be a waste of time, even though the timer hardware may not need to be
228 the target residency within the time until the expected wakeup, so that state is
232 waste of time and in this case the timer hardware would need to be reprogrammed,
234 does not occur any time soon, the hardware may spend indefinite amount of time
247 loop altogether.  That can be done through the build-time configuration of it
272 It first obtains the time until the closest timer event with the assumption
273 that the scheduler tick will be stopped.  That time, referred to as the *sleep
274 length* in what follows, is the upper bound on the time before the next CPU
294 values and, when predicting the idle duration next time, it computes the average
310 idle state is comparable with the predicted idle duration, the total time spent
335 the real time until the closest timer event and if it really is greater than
336 that time, the governor may need to select a shallower state with a suitable
358 values less than the current time till the closest timer (with the scheduler
362 the *sleep length*, which is the time until the closest timer event with the
364 on the time until the next CPU wakeup).  That value is then used to preselect an
370 sleep length.  They both are subject to decay (after a CPU wakeup) every time
377 the next idle state is greater than the observed idle duration at the same time
421 reflect the real time until the closest timer event and if it really is greater
422 than that time, a shallower state with a suitable target residency may need to
431 For the CPU idle time management purposes all of the physical idle states
451 idle state "X" must reflect the minimum time to spend in idle state "MX" of
452 the module (including the time needed to enter it), because that is the minimum
453 time the CPU needs to be idle to save any energy in case the hardware enters
455 the exit time of idle state "MX" of the module (and usually its entry time too),
456 because that is the maximum delay between a wakeup signal and the time the CPU
483 CPU at the initialization time.  That directory contains a set of subdirectories
523 ``time``
524 	Total time spent in this idle state by the given CPU (as measured by the
552 CPUs in the system at the same time.  Writing 1 to it causes the idle state to
565 The number in the :file:`time` file generally may be greater than the total time
569 enter any idle state at all).  The kernel can only measure the time span between
576 much time has been spent by the hardware in different idle states supported by
595 CPU idle time management can be affected by PM QoS in two ways, through the
605 ``<N>`` is allocated at the system initialization time.  Negative values
652 CPU in question every time the list of requests is updated this way or another
655 CPU idle time governors are expected to regard the minimum of the global
667 command line parameters affecting CPU idle time management.
670 CPU idle time management entirely.  It does not prevent the idle loop from
671 running on idle CPUs, but it prevents the CPU idle time governors and drivers
687 The other kernel command line parameters controlling CPU idle time management
692 options related to CPU idle time management: ``idle=poll``, ``idle=halt``,
720 idle time management, there are parameters affecting individual ``CPUIdle``