Lines Matching +full:down +full:- +full:scaling
5 CPU Performance Scaling
12 The Concept of CPU Performance Scaling
17 Operating Performance Points or P-states (in ACPI terminology). As a rule,
21 time (or the more power is drawn) by the CPU in the given P-state. Therefore
26 as possible and then there is no reason to use any P-states different from the
27 highest one (i.e. the highest-performance frequency/voltage configuration
35 put into different P-states.
38 capacity, so as to decide which P-states to put the CPUs into. Of course, since
41 to as CPU performance scaling or CPU frequency scaling (because it involves
45 CPU Performance Scaling in Linux
48 The Linux kernel supports CPU performance scaling by means of the ``CPUFreq``
49 (CPU Frequency scaling) subsystem that consists of three layers of code: the
50 core, scaling governors and scaling drivers.
53 interfaces for all platforms that support CPU performance scaling. It defines
56 Scaling governors implement algorithms to estimate the required CPU capacity.
57 As a rule, each governor implements one, possibly parametrized, scaling
60 Scaling drivers talk to the hardware. They provide scaling governors with
61 information on the available P-states (or P-state ranges in some cases) and
62 access platform-specific hardware interfaces to change CPU P-states as requested
63 by scaling governors.
65 In principle, all available scaling governors can be used with every scaling
67 performance scaling algorithms for P-state selection can be represented in a
68 platform-independent form in the majority of cases, so it should be possible
69 to use the same performance scaling algorithm implemented in exactly the same
70 way regardless of which scaling driver is used. Consequently, the same set of
71 scaling governors should be suitable for every supported platform.
73 However, that observation may not hold for performance scaling algorithms
77 platform-independent way. For this reason, ``CPUFreq`` allows scaling drivers
78 to bypass the governor layer and implement their own performance scaling
79 algorithms. That is done by the |intel_pstate| scaling driver.
85 In some cases the hardware interface for P-state control is shared by multiple
87 control the P-state of multiple CPUs at the same time and writing to it affects
90 Sets of CPUs sharing hardware P-state control interfaces are represented by
97 CPUs share the same hardware P-state control interface, all of the pointers
107 First of all, a scaling driver has to be registered for ``CPUFreq`` to work.
108 It is only possible to register one scaling driver at a time, so the scaling
111 The scaling driver may be registered before or after CPU registration. If
114 scaling driver. In turn, if any CPUs are registered after the registration of
115 the scaling driver, the ``CPUFreq`` core will be invoked to take note of them
120 logical CPU may be a physical single-core processor, or a single core in a
132 Next, the scaling driver's ``->init()`` callback is invoked with the policy
134 to initialize the performance scaling hardware interface for the given CPU (or,
139 the set of supported P-states is not a continuous range), and the mask of CPUs
145 scaling governor to it (to begin with, that is the default scaling governor
148 governor's ``->init()`` callback which is expected to initialize all of the
151 invoking its ``->start()`` callback.
153 That callback it expected to register per-CPU utilization update callbacks for
159 to determine the P-state to use for the given policy going forward and to
160 invoke the scaling driver to make changes to the hardware in accordance with
161 the P-state selection. The scaling driver may be invoked directly from
163 on the configuration and capabilities of the scaling driver and the governor.
168 to use the scaling governor previously used with the policy that became
169 "inactive" (and is re-initialized now) instead of the default governor.
173 need to re-initialize the policy object at all. In that case, it only is
174 necessary to restart the scaling governor so that it can take the new online CPU
175 into account. That is achieved by invoking the governor's ``->stop`` and
176 ``->start()`` callbacks, in this order, for the entire policy.
178 As mentioned before, the |intel_pstate| scaling driver bypasses the scaling
179 governor layer of ``CPUFreq`` and provides its own P-state selection algorithms.
180 Consequently, if |intel_pstate| is used, scaling governors are not attached to
181 new policy objects. Instead, the driver's ``->setpolicy()`` callback is invoked
182 to register per-CPU utilization update callbacks for each policy. These
183 callbacks are invoked by the CPU scheduler in the same way as for scaling
184 governors, but in the |intel_pstate| case they both determine the P-state to
189 associated with them are torn down when the scaling driver is unregistered
207 in :file:`/sys/devices/system/cpu/cpufreq` each contain policy-specific
212 and their behavior generally does not depend on what scaling driver is in use
213 and what scaling governor is attached to the given policy. Some scaling drivers
214 also add driver-specific attributes to the policy directories in ``sysfs`` to
215 control policy-specific aspects of driver behavior.
222 performance scaling interface represented by the ``policyX`` policy
232 BIOS/HW-based mechanisms.
237 This attribute is not present if the scaling driver in use does not
258 P-state to another, in nanoseconds.
260 If unknown or if known to be so high that the scaling driver does not
261 work with the `ondemand`_ governor, -1 (:c:macro:`CPUFREQ_ETERNAL`)
268 List of ``CPUFreq`` scaling governors present in the kernel that can
269 be attached to this policy or (if the |intel_pstate| scaling driver is
270 in use) list of scaling algorithms provided by the driver that can be
280 In the majority of cases, this is the frequency of the last P-state
281 requested by the scaling driver from the hardware using the scaling
292 The scaling driver currently in use.
295 The scaling governor currently attached to this policy or (if the
296 |intel_pstate| scaling driver is in use) the scaling algorithm
299 This attribute is read-write and writing to it will cause a new scaling
300 governor to be attached to this policy or a new scaling algorithm
301 provided by the scaling driver to be applied to it (in the
310 This attribute is read-write and writing a string representing an
318 This attribute is read-write and writing a string representing a
319 non-negative integer to it will cause a new limit to be set (it must not
323 This attribute is functional only if the `userspace`_ scaling governor
330 Generic Scaling Governors
333 ``CPUFreq`` provides generic scaling governors that can be used with all
334 scaling drivers. As stated before, each of them implements a single, possibly
335 parametrized, performance scaling algorithm.
337 Scaling governors are attached to policy objects and different policy objects
338 can be handled by different scaling governors at the same time (although that
341 The scaling governor for a given policy object can be changed at any time with
344 Some governors expose ``sysfs`` attributes to control or fine-tune the scaling
346 tunables, can be either global (system-wide) or per-policy, depending on the
347 scaling driver in use. If the driver requires governor tunables to be
348 per-policy, they are located in a subdirectory of each policy directory.
355 ---------------
365 -------------
375 -------------
382 -------------
389 invoke the scaling driver asynchronously when it decides that the CPU frequency
398 Per-Entity Load Tracking (PELT) metric for the root control group of the
399 given CPU as the CPU utilization estimate (see the `Per-entity load tracking`_
407 policy (if the PELT number is frequency-invariant), or the current CPU frequency
412 "IO-wait boosting". That happens when the :c:macro:`SCHED_CPUFREQ_IOWAIT` flag
421 runs of governor computations (default: 1000 times the scaling driver's
435 ------------
441 time in which the given CPU was not idle. The ratio of the non-idle (active)
449 invoked asynchronously (via a workqueue) and CPU P-states are updated from
452 relatively often and the CPU P-state updates triggered by it can be relatively
477 If this tunable is per-policy, the following shell command sets the time
521 f * (1 - ``powersave_bias`` / 1000)
535 The performance of a workload with the sensitivity of 0 (memory-bound or
536 IO-bound) is not expected to increase at all as a result of increasing
538 (CPU-bound) are expected to perform much better if the CPU frequency is
544 target, so as to avoid over-provisioning workloads that will not benefit
548 ----------------
557 battery-powered). To achieve that, it changes the frequency in relatively
558 small steps, one step at a time, up or down - depending on whether or not a
581 go down. Otherwise, the frequency will not be changed.
587 It effectively causes the frequency to go down ``sampling_down_factor``
595 ----------
604 "Turbo-Core" or (in technical documentation) "Core Performance Boost" and so on.
609 The frequency boost mechanism may be either hardware-based or software-based.
610 If it is hardware-based (e.g. on x86), the decision to trigger the boosting is
613 limits). If it is software-based (e.g. on ARM), the scaling driver decides
617 -------------------------------
621 scaling driver does not support the frequency boost mechanism (or supports it,
622 but provides a driver-specific interface for controlling it, like
627 trigger boosting (in the hardware-based case), or the software is allowed to
628 trigger boosting (in the software-based case). It does not mean that boosting
639 --------------------------------
669 single-thread performance may vary because of it which may lead to
675 -----------------------
677 The AMD powernow-k8 scaling driver supports a ``sysfs`` knob very similar to
684 implementation, however, works on the system-wide basis and setting that knob
701 .. _Per-entity load tracking: https://lwn.net/Articles/531853/