Lines Matching +full:down +full:- +full:scaling
1 .. SPDX-License-Identifier: GPL-2.0
7 CPU Performance Scaling
15 The Concept of CPU Performance Scaling
20 Operating Performance Points or P-states (in ACPI terminology). As a rule,
24 time (or the more power is drawn) by the CPU in the given P-state. Therefore
29 as possible and then there is no reason to use any P-states different from the
30 highest one (i.e. the highest-performance frequency/voltage configuration
38 put into different P-states.
41 capacity, so as to decide which P-states to put the CPUs into. Of course, since
44 to as CPU performance scaling or CPU frequency scaling (because it involves
48 CPU Performance Scaling in Linux
51 The Linux kernel supports CPU performance scaling by means of the ``CPUFreq``
52 (CPU Frequency scaling) subsystem that consists of three layers of code: the
53 core, scaling governors and scaling drivers.
56 interfaces for all platforms that support CPU performance scaling. It defines
59 Scaling governors implement algorithms to estimate the required CPU capacity.
60 As a rule, each governor implements one, possibly parametrized, scaling
63 Scaling drivers talk to the hardware. They provide scaling governors with
64 information on the available P-states (or P-state ranges in some cases) and
65 access platform-specific hardware interfaces to change CPU P-states as requested
66 by scaling governors.
68 In principle, all available scaling governors can be used with every scaling
70 performance scaling algorithms for P-state selection can be represented in a
71 platform-independent form in the majority of cases, so it should be possible
72 to use the same performance scaling algorithm implemented in exactly the same
73 way regardless of which scaling driver is used. Consequently, the same set of
74 scaling governors should be suitable for every supported platform.
76 However, that observation may not hold for performance scaling algorithms
80 platform-independent way. For this reason, ``CPUFreq`` allows scaling drivers
81 to bypass the governor layer and implement their own performance scaling
82 algorithms. That is done by the |intel_pstate| scaling driver.
88 In some cases the hardware interface for P-state control is shared by multiple
90 control the P-state of multiple CPUs at the same time and writing to it affects
93 Sets of CPUs sharing hardware P-state control interfaces are represented by
100 CPUs share the same hardware P-state control interface, all of the pointers
110 First of all, a scaling driver has to be registered for ``CPUFreq`` to work.
111 It is only possible to register one scaling driver at a time, so the scaling
114 The scaling driver may be registered before or after CPU registration. If
117 scaling driver. In turn, if any CPUs are registered after the registration of
118 the scaling driver, the ``CPUFreq`` core will be invoked to take note of them
123 logical CPU may be a physical single-core processor, or a single core in a
135 Next, the scaling driver's ``->init()`` callback is invoked with the policy
137 to initialize the performance scaling hardware interface for the given CPU (or,
142 the set of supported P-states is not a continuous range), and the mask of CPUs
148 scaling governor to it (to begin with, that is the default scaling governor
151 the governor's ``->init()`` callback which is expected to initialize all of the
154 invoking its ``->start()`` callback.
156 That callback is expected to register per-CPU utilization update callbacks for
162 to determine the P-state to use for the given policy going forward and to
163 invoke the scaling driver to make changes to the hardware in accordance with
164 the P-state selection. The scaling driver may be invoked directly from
166 on the configuration and capabilities of the scaling driver and the governor.
171 to use the scaling governor previously used with the policy that became
172 "inactive" (and is re-initialized now) instead of the default governor.
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
178 into account. That is achieved by invoking the governor's ``->stop`` and
179 ``->start()`` callbacks, in this order, for the entire policy.
181 As mentioned before, the |intel_pstate| scaling driver bypasses the scaling
182 governor layer of ``CPUFreq`` and provides its own P-state selection algorithms.
183 Consequently, if |intel_pstate| is used, scaling governors are not attached to
184 new policy objects. Instead, the driver's ``->setpolicy()`` callback is invoked
185 to register per-CPU utilization update callbacks for each policy. These
186 callbacks are invoked by the CPU scheduler in the same way as for scaling
187 governors, but in the |intel_pstate| case they both determine the P-state to
192 associated with them are torn down when the scaling driver is unregistered
210 in :file:`/sys/devices/system/cpu/cpufreq` each contain policy-specific
215 and their behavior generally does not depend on what scaling driver is in use
216 and what scaling governor is attached to the given policy. Some scaling drivers
217 also add driver-specific attributes to the policy directories in ``sysfs`` to
218 control policy-specific aspects of driver behavior.
225 performance scaling interface represented by the ``policyX`` policy
235 BIOS/HW-based mechanisms.
240 This attribute is not present if the scaling driver in use does not
275 P-state to another, in nanoseconds.
285 List of ``CPUFreq`` scaling governors present in the kernel that can
286 be attached to this policy or (if the |intel_pstate| scaling driver is
287 in use) list of scaling algorithms provided by the driver that can be
297 In the majority of cases, this is the frequency of the last P-state
298 requested by the scaling driver from the hardware using the scaling
310 The scaling driver currently in use.
313 The scaling governor currently attached to this policy or (if the
314 |intel_pstate| scaling driver is in use) the scaling algorithm
317 This attribute is read-write and writing to it will cause a new scaling
318 governor to be attached to this policy or a new scaling algorithm
319 provided by the scaling driver to be applied to it (in the
328 This attribute is read-write and writing a string representing an
336 This attribute is read-write and writing a string representing a
337 non-negative integer to it will cause a new limit to be set (it must not
341 This attribute is functional only if the `userspace`_ scaling governor
348 Generic Scaling Governors
351 ``CPUFreq`` provides generic scaling governors that can be used with all
352 scaling drivers. As stated before, each of them implements a single, possibly
353 parametrized, performance scaling algorithm.
355 Scaling governors are attached to policy objects and different policy objects
356 can be handled by different scaling governors at the same time (although that
359 The scaling governor for a given policy object can be changed at any time with
362 Some governors expose ``sysfs`` attributes to control or fine-tune the scaling
364 tunables, can be either global (system-wide) or per-policy, depending on the
365 scaling driver in use. If the driver requires governor tunables to be
366 per-policy, they are located in a subdirectory of each policy directory.
373 ---------------
383 -------------
393 -------------
402 -------------
409 invoke the scaling driver asynchronously when it decides that the CPU frequency
418 Per-Entity Load Tracking (PELT) metric for the root control group of the
419 given CPU as the CPU utilization estimate (see the *Per-entity load tracking*
427 policy (if the PELT number is frequency-invariant), or the current CPU frequency
432 "IO-wait boosting". That happens when the :c:macro:`SCHED_CPUFREQ_IOWAIT` flag
441 runs of governor computations (default: 1.5 times the scaling driver's
455 ------------
461 time in which the given CPU was not idle. The ratio of the non-idle (active)
469 invoked asynchronously (via a workqueue) and CPU P-states are updated from
472 relatively often and the CPU P-state updates triggered by it can be relatively
496 If this tunable is per-policy, the following shell command sets the time
541 f * (1 - ``powersave_bias`` / 1000)
555 The performance of a workload with the sensitivity of 0 (memory-bound or
556 IO-bound) is not expected to increase at all as a result of increasing
558 (CPU-bound) are expected to perform much better if the CPU frequency is
564 target, so as to avoid over-provisioning workloads that will not benefit
568 ----------------
577 battery-powered). To achieve that, it changes the frequency in relatively
578 small steps, one step at a time, up or down - depending on whether or not a
601 go down. Otherwise, the frequency will not be changed.
607 It effectively causes the frequency to go down ``sampling_down_factor``
615 ----------
624 "Turbo-Core" or (in technical documentation) "Core Performance Boost" and so on.
629 The frequency boost mechanism may be either hardware-based or software-based.
630 If it is hardware-based (e.g. on x86), the decision to trigger the boosting is
633 limits). If it is software-based (e.g. on ARM), the scaling driver decides
637 -------------------------------
641 scaling driver does not support the frequency boost mechanism (or supports it,
642 but provides a driver-specific interface for controlling it, like
647 trigger boosting (in the hardware-based case), or the software is allowed to
648 trigger boosting (in the software-based case). It does not mean that boosting
659 --------------------------------
689 single-thread performance may vary because of it which may lead to
695 -----------------------
697 The AMD powernow-k8 scaling driver supports a ``sysfs`` knob very similar to
704 implementation, however, works on the system-wide basis and setting that knob
724 .. [1] Jonathan Corbet, *Per-entity load tracking*,