Lines Matching full:it
28 In some situations it is desirable or even necessary to run the program as fast
31 available). In some other cases, however, it may not be necessary to execute
33 relatively long time without utilizing it entirely may be regarded as wasteful.
34 It also may not be physically possible to maintain maximum CPU capacity for too
44 to as CPU performance scaling or CPU frequency scaling (because it involves
56 interfaces for all platforms that support CPU performance scaling. It defines
71 platform-independent form in the majority of cases, so it should be possible
79 interface it comes from and may not be easily represented in an abstract,
90 control the P-state of multiple CPUs at the same time and writing to it affects
111 It is only possible to register one scaling driver at a time, so the scaling
121 In any case, the ``CPUFreq`` core is invoked to take note of any logical CPU it
122 has not seen so far as soon as it is ready to handle that CPU. [Note that the
130 for the given CPU and if so, it skips the policy object creation. Otherwise,
136 pointer of the new CPU passed to it as the argument. That callback is expected
138 more precisely, for the set of CPUs sharing the hardware interface it belongs
139 to, represented by its policy object) and, if the policy object it has been
145 CPUs in it.
148 scaling governor to it (to begin with, that is the default scaling governor
149 determined by the kernel command line or configuration, but it may be changed
153 a governor ``sysfs`` interface to it. Next, the governor is started by
175 other CPUs sharing the policy object with it are online already, there is no
176 need to re-initialize the policy object at all. In that case, it only is
177 necessary to restart the scaling governor so that it can take the new online CPU
193 (which happens when the kernel module containing it is unloaded, for example) or
241 support it.
260 The time it takes to switch the CPUs belonging to this policy from one
280 [Note that some governors are modular and it may be necessary to load a
281 kernel module for the governor held by it to become available and be
289 interface provided by it, which may or may not reflect the frequency
306 This attribute is read-write and writing to it will cause a new scaling
308 provided by the scaling driver to be applied to it (in the
318 integer to it will cause a new limit to be set (it must not be lower
326 non-negative integer to it will cause a new limit to be set (it must not
333 It returns the last frequency requested by the governor (in kHz) or can
384 This governor does not do anything by itself. Instead, it allows user space
385 to set the CPU frequency for the policy it is attached to by writing to the
391 This governor uses CPU utilization data available from the CPU scheduler. It
392 generally is regarded as a part of the CPU scheduler, so it can access the
395 It runs entirely in scheduler context, although in some cases it may need to
396 invoke the scaling driver asynchronously when it decides that the CPU frequency
401 invoking its utilization update callback for that CPU. If it is invoked by the
404 if it is invoked by the CFS scheduling class, the governor will use the
417 This governor also employs a mechanism allowing it to temporarily bump up the
432 of the governor which might be excessive without it.
435 and `conservative`_ governors (described below), as it is simpler and more
437 switches and similar is less significant, and it uses the scheduler's own CPU
446 In order to estimate the current CPU load, it measures the time elapsed between
455 The worker routine of this governor has to run in process context, so it is
458 governor is minimum, but it causes additional CPU context switches to happen
459 relatively often and the CPU P-state updates triggered by it can be relatively
460 irregular. Also, it affects its own CPU load metric by running code that
462 slightly by it).
464 It generally selects CPU frequencies proportional to the estimated load, so that
468 speedup threshold, in which case it will go straight for the highest frequency
469 it is allowed to use (the ``scaling_max_freq`` policy limit).
477 Typically, it is set to values of the order of 2000 (2 ms). Its
484 represented by it to be 1.5 times as high as the transition latency
496 If set to 1 (default 0), it will cause the CPU load estimation code to
502 Then, to make that happen it is sufficient to increase the "nice" level
534 value of this attribute is 400 by default and it is used in a different
559 It estimates the CPU load in the same way as the `ondemand`_ governor described
560 above, but the CPU frequency selection algorithm implemented by it is different.
562 Namely, it avoids changing the frequency significantly over short time intervals
564 battery-powered). To achieve that, it changes the frequency in relatively
576 it to 0 will cause the default frequency step (5 percent) to be used
577 and setting it to 100 effectively causes the governor to periodically
594 It effectively causes the frequency to go down ``sampling_down_factor``
595 times slower than it ramps up.
610 For Intel processors it is referred to as "Turbo Boost", AMD calls it
612 As a rule, it also is implemented differently by different vendors. The simple
617 If it is hardware-based (e.g. on x86), the decision to trigger the boosting is
618 made by the hardware (although in general it requires the hardware to be put
619 into a special state in which it can control the CPU frequency within certain
620 limits). If it is software-based (e.g. on ARM), the scaling driver decides
627 the "boost" setting for the whole system. It is not present if the underlying
628 scaling driver does not support the frequency boost mechanism (or supports it,
629 but provides a driver-specific interface for controlling it, like
633 means that either the hardware can be put into states in which it is able to
635 trigger boosting (in the software-based case). It does not mean that boosting
636 is actually in use at the moment on any CPUs in the system. It only means a
650 scheduler tick interval) and it is demonstrably suitable for many workloads, but
651 it may lead to problems in certain situations.
653 For this reason, many systems make it possible to disable the frequency boost
670 3. To examine the impact of the frequency boost mechanism itself, it is useful
676 single-thread performance may vary because of it which may lead to
685 the global ``boost`` one. It is used for disabling/enabling the "Core
692 for one policy causes the same value of it to be set for all of the other
696 hardware feature, but it may be configured out of the kernel (via the
698 ``boost`` knob is present regardless. Thus it is always possible use the