Lines Matching full:to
20 different clock frequency and voltage configurations, often referred to as
29 In some situations it is desirable or even necessary to run the program as fast
30 as possible and then there is no reason to use any P-states different from the
32 available). In some other cases, however, it may not be necessary to execute
35 It also may not be physically possible to maintain maximum CPU capacity for too
36 long for thermal or power supply capacity reasons or similar. To cover those
37 cases, there are hardware interfaces allowing CPUs to be switched between
38 different frequency/voltage configurations or (in the ACPI terminology) to be
41 Typically, they are used along with algorithms to estimate the required CPU
42 capacity, so as to decide which P-states to put the CPUs into. Of course, since
43 the utilization of the system generally changes over time, that has to be done
45 to as CPU performance scaling or CPU frequency scaling (because it involves
60 Scaling governors implement algorithms to estimate the required CPU capacity.
64 Scaling drivers talk to the hardware. They provide scaling governors with
66 access platform-specific hardware interfaces to change CPU P-states as requested
73 to use the same performance scaling algorithm implemented in exactly the same
79 feedback registers, as that information is typically specific to the hardware
82 to bypass the governor layer and implement their own performance scaling
90 CPUs. That is, for example, the same register (or set of registers) is used to
91 control the P-state of multiple CPUs at the same time and writing to it affects
99 The ``CPUFreq`` core maintains a pointer to a |struct cpufreq_policy| object for
102 corresponding to them point to the same |struct cpufreq_policy| object.
111 First of all, a scaling driver has to be registered for ``CPUFreq`` to work.
112 It is only possible to register one scaling driver at a time, so the scaling
113 driver is expected to be able to handle all CPUs in the system.
116 CPUs are registered earlier, the driver core invokes the ``CPUFreq`` core to
119 the scaling driver, the ``CPUFreq`` core will be invoked to take note of them
122 In any case, the ``CPUFreq`` core is invoked to take note of any logical CPU it
123 has not seen so far as soon as it is ready to handle that CPU. [Note that the
127 otherwise and the word "processor" is used to refer to the physical part
133 a new policy directory in ``sysfs``, and the policy pointer corresponding to
134 the given CPU is set to the new policy object's address in memory.
137 pointer of the new CPU passed to it as the argument. That callback is expected
138 to initialize the performance scaling hardware interface for the given CPU (or,
140 to, represented by its policy object) and, if the policy object it has been
141 called for is new, to set parameters of the policy, like the minimum and maximum
144 that belong to the same policy (including both online and offline CPUs). That
145 mask is then used by the core to populate the policy pointers for all of the
148 The next major initialization step for a new policy object is to attach a
149 scaling governor to it (to begin with, that is the default scaling governor
151 via ``sysfs``). First, a pointer to the new policy object is passed to the
152 governor's ``->init()`` callback which is expected to initialize all of the
153 data structures necessary to handle the given policy and, possibly, to add
154 a governor ``sysfs`` interface to it. Next, the governor is started by
157 That callback is expected to register per-CPU utilization update callbacks for
158 all of the online CPUs belonging to the given policy with the CPU scheduler.
162 scheduler's perspective). They are expected to carry out computations needed
163 to determine the P-state to use for the given policy going forward and to
164 invoke the scaling driver to make changes to the hardware in accordance with
170 previously, meaning that all of the CPUs belonging to them were offline. The
172 to use the scaling governor previously used with the policy that became
177 need to re-initialize the policy object at all. In that case, it only is
178 necessary to restart the scaling governor so that it can take the new online CPU
184 Consequently, if |intel_pstate| is used, scaling governors are not attached to
186 to register per-CPU utilization update callbacks for each policy. These
188 governors, but in the |intel_pstate| case they both determine the P-state to
195 when the last CPU belonging to the given policy in unregistered.
207 Each ``policyX`` directory is pointed to by ``cpufreq`` symbolic links
210 associated with (or belonging to) the given policy. The ``policyX`` directories
212 attributes (files) to control ``CPUFreq`` behavior for the corresponding policy
217 and what scaling governor is attached to the given policy. Some scaling drivers
218 also add driver-specific attributes to the policy directories in ``sysfs`` to
225 List of online CPUs belonging to this policy (i.e. sharing the hardware
230 If the platform firmware (BIOS) tells the OS to apply an upper limit to
245 Current frequency of the CPUs belonging to this policy as obtained from
248 This is expected to be the frequency the hardware actually runs at.
253 Maximum possible operating frequency the CPUs belonging to this policy
257 Minimum possible operating frequency the CPUs belonging to this policy
261 The time it takes to switch the CPUs belonging to this policy from one
262 P-state to another, in nanoseconds.
264 If unknown or if known to be so high that the scaling driver does not
269 List of all (online and offline) CPUs belonging to this policy.
273 be attached to this policy or (if the |intel_pstate| scaling driver is
275 applied to this policy.
277 [Note that some governors are modular and it may be necessary to load a
278 kernel module for the governor held by it to become available and be
282 Current frequency of all of the CPUs belonging to this policy (in kHz).
287 the CPU is actually running at (due to hardware design and other
290 Some architectures (e.g. ``x86``) may attempt to provide information
299 The scaling governor currently attached to this policy or (if the
301 provided by the driver that is currently applied to this policy.
303 This attribute is read-write and writing to it will cause a new scaling
304 governor to be attached to this policy or a new scaling algorithm
305 provided by the scaling driver to be applied to it (in the
306 |intel_pstate| case), as indicated by the string written to this
311 Maximum frequency the CPUs belonging to this policy are allowed to be
315 integer to it will cause a new limit to be set (it must not be lower
319 Minimum frequency the CPUs belonging to this policy are allowed to be
323 non-negative integer to it will cause a new limit to be set (it must not
328 is attached to the given policy.
331 be written to in order to set a new frequency for the policy.
341 Scaling governors are attached to policy objects and different policy objects
343 may lead to suboptimal results in some cases).
348 Some governors expose ``sysfs`` attributes to control or fine-tune the scaling
349 algorithms implemented by them. Those attributes, referred to as governor
351 scaling driver in use. If the driver requires governor tunables to be
361 When attached to a policy object, this governor causes the highest frequency,
362 within the ``scaling_max_freq`` policy limit, to be requested for that policy.
364 The request is made once at that time the governor for the policy is set to
371 When attached to a policy object, this governor causes the lowest frequency,
372 within the ``scaling_min_freq`` policy limit, to be requested for that policy.
374 The request is made once at that time the governor for the policy is set to
382 to set the CPU frequency for the policy it is attached to by writing to the
392 It runs entirely in scheduler context, although in some cases it may need to
399 RT or deadline scheduling classes, the governor will increase the frequency to
405 CPU frequency to apply is computed in accordance with the formula
414 This governor also employs a mechanism allowing it to temporarily bump up the
417 is passed by the scheduler to the governor callback which causes the frequency
418 to go up to the allowed maximum immediately and then draw back to the value
424 Minimum time (in microseconds) that has to pass between two consecutive
428 The purpose of this tunable is to reduce the scheduler context overhead
443 In order to estimate the current CPU load, it measures the time elapsed between
446 time to the total CPU time is taken as an estimate of the load.
448 If this governor is attached to a policy shared by multiple CPUs, the load is
452 The worker routine of this governor has to run in process context, so it is
455 governor is minimum, but it causes additional CPU context switches to happen
461 It generally selects CPU frequencies proportional to the estimated load, so that
462 the value of the ``cpuinfo_max_freq`` policy attribute corresponds to the load of
464 corresponds to the load of 0, unless when the load exceeds a (configurable)
466 it is allowed to use (the ``scaling_max_freq`` policy limit).
474 Typically, it is set to values of the order of 10000 (10 ms). Its
475 default value is equal to the value of ``cpuinfo_transition_latency``
476 for each policy this governor is attached to (but since the unit here
482 represented by it to be 750 times as high as the transition latency::
488 will set the frequency to the maximum value allowed for the policy.
489 Otherwise, the selected frequency will be proportional to the estimated
493 If set to 1 (default 0), it will cause the CPU load estimation code to
498 taken into account when deciding what frequency to run the CPUs at.
499 Then, to make that happen it is sufficient to increase the "nice" level
500 of those tasks above 0 and set this attribute to 1.
503 Temporary multiplier, between 1 (default) and 100 inclusive, to apply to
507 setting the frequency to the allowed maximum) to be delayed, so the
515 Reduction factor to apply to the original frequency target of the
523 the effective frequency to apply is given by
534 On Family 16h (and later) AMD processors there is a mechanism to get a
536 hardware. That value can be used to estimate how the performance of the
537 workload running on a CPU will change in response to frequency changes.
540 IO-bound) is not expected to increase at all as a result of increasing
542 (CPU-bound) are expected to perform much better if the CPU frequency is
547 will cause the governor to select a frequency lower than its original
548 target, so as to avoid over-provisioning workloads that will not benefit
561 battery-powered). To achieve that, it changes the frequency in relatively
569 allowed to set (the ``scaling_max_freq`` policy limit), between 0 and
572 This is how much the frequency is allowed to change in one go. Setting
573 it to 0 will cause the default frequency step (5 percent) to be used
574 and setting it to 100 effectively causes the governor to periodically
579 Threshold value (in percent, 20 by default) used to determine the
591 It effectively causes the frequency to go down ``sampling_down_factor``
601 Some processors support a mechanism to raise the operating frequency of some
606 Different names are used by different vendors to refer to this functionality.
607 For Intel processors it is referred to as "Turbo Boost", AMD calls it
610 term "frequency boost" is used here for brevity to refer to all of those
614 If it is hardware-based (e.g. on x86), the decision to trigger the boosting is
615 made by the hardware (although in general it requires the hardware to be put
618 whether or not to trigger boosting and when to do that.
630 means that either the hardware can be put into states in which it is able to
631 trigger boosting (in the hardware-based case), or the software is allowed to
634 permission to use the frequency boost mechanism (which still may never be used
640 The only values that can be written to this file are 0 and 1.
645 The frequency boost mechanism is generally intended to help to achieve optimum
648 it may lead to problems in certain situations.
650 For this reason, many systems make it possible to disable the frequency boost
651 mechanism in the platform firmware (BIOS) setup, but that requires the system to
652 be restarted for the setting to be adjusted as desired, which may not be
658 That may not be desirable on systems that switch to power sources of
659 limited capacity, such as batteries, so the ability to disable the boost
664 performance or energy consumption (or both) and the ability to disable
667 3. To examine the impact of the frequency boost mechanism itself, it is useful
668 to be able to run tests with and without boosting, preferably without
673 single-thread performance may vary because of it which may lead to
675 frequency boost mechanism before running benchmarks sensitive to that
681 The AMD powernow-k8 scaling driver supports a ``sysfs`` knob very similar to
689 for one policy causes the same value of it to be set for all of the other