Lines Matching +full:hardware +full:- +full:based
1 .. SPDX-License-Identifier: GPL-2.0
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
36 cases, there are hardware interfaces allowing CPUs to be switched between
38 put into different P-states.
41 capacity, so as to decide which P-states to put the CPUs into. Of course, since
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
69 driver. That design is based on the observation that the information used by
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
77 based on information provided by the hardware itself, for example through
78 feedback registers, as that information is typically specific to the hardware
80 platform-independent way. For this reason, ``CPUFreq`` allows scaling drivers
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
104 of its user space interface is based on the policy concept.
123 logical CPU may be a physical single-core processor, or a single core in a
124 multicore processor, or a hardware thread in a physical processor or processor
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,
138 more precisely, for the set of CPUs sharing the hardware interface it belongs
141 frequencies supported by the hardware, the table of available frequencies (if
142 the set of supported P-states is not a continuous range), and the mask of CPUs
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
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
178 into account. That is achieved by invoking the governor's ``->stop`` and
179 ``->start()`` callbacks, in this order, for the entire policy.
182 governor layer of ``CPUFreq`` and provides its own P-state selection algorithms.
184 new policy objects. Instead, the driver's ``->setpolicy()`` callback is invoked
185 to register per-CPU utilization update callbacks for each policy. These
187 governors, but in the |intel_pstate| case they both determine the P-state to
188 use and change the hardware configuration accordingly in one go from scheduler
210 in :file:`/sys/devices/system/cpu/cpufreq` each contain policy-specific
217 also add driver-specific attributes to the policy directories in ``sysfs`` to
218 control policy-specific aspects of driver behavior.
224 List of online CPUs belonging to this policy (i.e. sharing the hardware
235 BIOS/HW-based mechanisms.
245 the hardware (in KHz).
247 This is expected to be the frequency the hardware actually runs at.
253 derived from a hardware provided feedback and reported on a time frame
256 This is expected to be based on the frequency the hardware actually runs
257 at and, as such, might require specialised hardware support (such as AMU
275 P-state to another, in nanoseconds.
278 work with the `ondemand`_ governor, -1 (:c:macro:`CPUFREQ_ETERNAL`)
301 In the majority of cases, this is the frequency of the last P-state
302 requested by the scaling driver from the hardware using the scaling
304 the CPU is actually running at (due to hardware design and other
310 seen by the hardware at the moment. This behavior though, is only
321 This attribute is read-write and writing to it will cause a new scaling
332 This attribute is read-write and writing a string representing an
340 This attribute is read-write and writing a string representing a
341 non-negative integer to it will cause a new limit to be set (it must not
366 Some governors expose ``sysfs`` attributes to control or fine-tune the scaling
368 tunables, can be either global (system-wide) or per-policy, depending on the
370 per-policy, they are located in a subdirectory of each policy directory.
377 ---------------
387 -------------
397 -------------
403 on hardware coordination, thermal and power limits, and other factors.
406 -------------
422 Per-Entity Load Tracking (PELT) metric for the root control group of the
423 given CPU as the CPU utilization estimate (see the *Per-entity load tracking*
431 policy (if the PELT number is frequency-invariant), or the current CPU frequency
436 "IO-wait boosting". That happens when the :c:macro:`SCHED_CPUFREQ_IOWAIT` flag
459 ------------
465 time in which the given CPU was not idle. The ratio of the non-idle (active)
473 invoked asynchronously (via a workqueue) and CPU P-states are updated from
476 relatively often and the CPU P-state updates triggered by it can be relatively
500 If this tunable is per-policy, the following shell command sets the time
545 f * (1 - ``powersave_bias`` / 1000)
556 hardware. That value can be used to estimate how the performance of the
559 The performance of a workload with the sensitivity of 0 (memory-bound or
560 IO-bound) is not expected to increase at all as a result of increasing
562 (CPU-bound) are expected to perform much better if the CPU frequency is
568 target, so as to avoid over-provisioning workloads that will not benefit
572 ----------------
581 battery-powered). To achieve that, it changes the frequency in relatively
582 small steps, one step at a time, up or down - depending on whether or not a
619 ----------
628 "Turbo-Core" or (in technical documentation) "Core Performance Boost" and so on.
633 The frequency boost mechanism may be either hardware-based or software-based.
634 If it is hardware-based (e.g. on x86), the decision to trigger the boosting is
635 made by the hardware (although in general it requires the hardware to be put
637 limits). If it is software-based (e.g. on ARM), the scaling driver decides
641 -------------------------------
646 but provides a driver-specific interface for controlling it, like
650 means that either the hardware can be put into states in which it is able to
651 trigger boosting (in the hardware-based case), or the software is allowed to
652 trigger boosting (in the software-based case). It does not mean that boosting
663 --------------------------------
693 single-thread performance may vary because of it which may lead to
699 -----------------------
701 The AMD powernow-k8 scaling driver supports a ``sysfs`` knob very similar to
708 implementation, however, works on the system-wide basis and setting that knob
713 hardware feature, but it may be configured out of the kernel (via the
721 hardware feature (e.g. all Intel ones), even if the
728 .. [1] Jonathan Corbet, *Per-entity load tracking*,