Lines Matching +full:cpufreq +full:- +full:hw
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
38 put into different P-states.
41 capacity, so as to decide which P-states to put the CPUs into. Of course, since
51 The Linux kernel supports CPU performance scaling by means of the ``CPUFreq``
55 The ``CPUFreq`` core provides the common code infrastructure and user space
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
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
80 platform-independent way. For this reason, ``CPUFreq`` allows scaling drivers
85 ``CPUFreq`` Policy Objects
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
94 ``CPUFreq`` as struct cpufreq_policy objects. For consistency,
98 The ``CPUFreq`` core maintains a pointer to a struct cpufreq_policy object for
100 CPUs share the same hardware P-state control interface, all of the pointers
103 ``CPUFreq`` uses struct cpufreq_policy as its basic data type and the design
110 First of all, a scaling driver has to be registered for ``CPUFreq`` to work.
115 CPUs are registered earlier, the driver core invokes the ``CPUFreq`` core to
118 the scaling driver, the ``CPUFreq`` core will be invoked to take note of them
121 In any case, the ``CPUFreq`` core is invoked to take note of any logical CPU it
123 logical CPU may be a physical single-core processor, or a single core in a
129 Once invoked, the ``CPUFreq`` core checks if the policy pointer is already set
135 Next, the scaling driver's ``->init()`` callback is invoked with the policy
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
164 the P-state selection. The scaling driver may be invoked directly from
170 only practical difference in that case is that the ``CPUFreq`` core will attempt
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
200 During the initialization of the kernel, the ``CPUFreq`` core creates a
201 ``sysfs`` directory (kobject) called ``cpufreq`` under
205 integer number) for every policy object maintained by the ``CPUFreq`` core.
206 Each ``policyX`` directory is pointed to by ``cpufreq`` symbolic links
210 in :file:`/sys/devices/system/cpu/cpufreq` each contain policy-specific
211 attributes (files) to control ``CPUFreq`` behavior for the corresponding policy
214 Some of those attributes are generic. They are created by the ``CPUFreq`` core
217 also add driver-specific attributes to the policy directories in ``sysfs`` to
218 control policy-specific aspects of driver behavior.
220 The generic attributes under :file:`/sys/devices/system/cpu/cpufreq/policyX/`
235 BIOS/HW-based mechanisms.
275 P-state to another, in nanoseconds.
278 work with the `ondemand`_ governor, -1 (:c:macro:`CPUFREQ_ETERNAL`)
289 List of ``CPUFreq`` scaling governors present in the kernel that can
301 In the majority of cases, this is the frequency of the last P-state
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
355 ``CPUFreq`` provides generic scaling governors that can be used with all
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.
372 :file:`/sys/devices/system/cpu/cpufreq/`. In either case the name of the
377 ---------------
387 -------------
397 -------------
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
539 (:file:`drivers/cpufreq/amd_freq_sensitivity.c`), between 0 and 1000
545 f * (1 - ``powersave_bias`` / 1000)
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
637 limits). If it is software-based (e.g. on ARM), the scaling driver decides
641 -------------------------------
643 This file is located under :file:`/sys/devices/system/cpu/cpufreq/` and controls
646 but provides a driver-specific interface for controlling it, like
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
705 If present, that knob is located in every ``CPUFreq`` policy directory in
706 ``sysfs`` (:file:`/sys/devices/system/cpu/cpufreq/policyX/`) and is called
708 implementation, however, works on the system-wide basis and setting that knob
728 .. [1] Jonathan Corbet, *Per-entity load tracking*,