Lines Matching full:scaling
7 CPU Performance Scaling
15 The Concept of CPU Performance Scaling
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
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
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.
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
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,
148 scaling governor to it (to begin with, that is the default scaling governor
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
177 necessary to restart the scaling governor so that it can take the new online CPU
181 As mentioned before, the |intel_pstate| scaling driver bypasses the scaling
183 Consequently, if |intel_pstate| is used, scaling governors are not attached to
186 callbacks are invoked by the CPU scheduler in the same way as for scaling
192 associated with them are torn down when the scaling driver is unregistered
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
225 performance scaling interface represented by the ``policyX`` policy
240 This attribute is not present if the scaling driver in use does not
263 If unknown or if known to be so high that the scaling driver does not
275 List of ``CPUFreq`` scaling governors present in the kernel that can
276 be attached to this policy or (if the |intel_pstate| scaling driver is
277 in use) list of scaling algorithms provided by the driver that can be
288 requested by the scaling driver from the hardware using the scaling
299 The scaling driver currently in use.
302 The scaling governor currently attached to this policy or (if the
303 |intel_pstate| scaling driver is in use) the scaling algorithm
306 This attribute is read-write and writing to it will cause a new scaling
307 governor to be attached to this policy or a new scaling algorithm
308 provided by the scaling driver to be applied to it (in the
330 This attribute is functional only if the `userspace`_ scaling governor
337 Generic Scaling Governors
340 ``CPUFreq`` provides generic scaling governors that can be used with all
341 scaling drivers. As stated before, each of them implements a single, possibly
342 parametrized, performance scaling algorithm.
344 Scaling governors are attached to policy objects and different policy objects
345 can be handled by different scaling governors at the same time (although that
348 The scaling governor for a given policy object can be changed at any time with
351 Some governors expose ``sysfs`` attributes to control or fine-tune the scaling
354 scaling driver in use. If the driver requires governor tunables to be
396 invoke the scaling driver asynchronously when it decides that the CPU frequency
428 runs of governor computations (default: 1.5 times the scaling driver's
620 limits). If it is software-based (e.g. on ARM), the scaling driver decides
628 scaling driver does not support the frequency boost mechanism (or supports it,
684 The AMD powernow-k8 scaling driver supports a ``sysfs`` knob very similar to