CPU frequency scaling: Difference between revisions

From ArchWiki
m (→‎CPU frequency driver: Minor typos, cleanup)
(→‎cpupower-gui: It is recommended to install the git version, which fixes quite a few general issues, namely to prevent freezing when applying settings, and better build in profiles. Please do not change back to cpupower-gui unless these issues have been tested and fixed. Here is my source https://github.com/vagnum08/cpupower-gui/issues/65#issuecomment-910938175. I have also included information about the services.)
 
(281 intermediate revisions by 71 users not shown)
Line 1: Line 1:
[[Category:Power management]]
[[Category:Power management]]
[[Category:CPU]]
[[Category:CPU]]
[[ar:CPU frequency scaling]]
[[cs:CPU frequency scaling]]
[[de:Cpufrequtils]]
[[de:Cpufrequtils]]
[[el:CPU frequency scaling]]
[[fr:CPU frequency scaling]]
[[es:CPU frequency scaling]]
[[fr:Cpufreq]]
[[it:CPU frequency scaling]]
[[ja:CPU 周波数スケーリング]]
[[ja:CPU 周波数スケーリング]]
[[pt:CPU frequency scaling]]
[[pt:CPU frequency scaling]]
[[ru:CPU frequency scaling]]
[[zh-hans:CPU frequency scaling]]
[[sk:CPU frequency scaling]]
[[tr:Işlemci frekansını ölçekleme]]
[[zh-cn:CPU frequency scaling]]
{{Related articles start}}
{{Related articles start}}
{{Related|Power saving}}
{{Related|Power saving}}
{{Related|Laptop Mode Tools}}
{{Related|Laptop Mode Tools}}
{{Related|pm-utils}}
{{Related|Undervolting CPU}}
{{Related|PHC}}
{{Related articles end}}
{{Related articles end}}


CPU frequency scaling enables the operating system to scale the CPU frequency up or down in order to save power. CPU frequencies can be scaled automatically depending on the system load, in response to ACPI events, or manually by userspace programs.
[https://docs.kernel.org/admin-guide/pm/cpufreq.html CPU performance scaling] enables the operating system to scale the CPU frequency up or down in order to save power or improve performance. Scaling can be done automatically in response to system load, adjust itself in response to ACPI events, or be manually changed by user space programs.


CPU frequency scaling is implemented in the Linux kernel, the infrastructure is called ''cpufreq''. Since kernel 3.4 the necessary modules are loaded automatically and the recommended [[#Scaling governors|ondemand governor]] is enabled by default. However, userspace tools like [[#cpupower|cpupower]], [[acpid]], [[Laptop Mode Tools]], or GUI tools provided for your desktop environment, may still be used for advanced configuration.
The Linux kernel offers CPU performance scaling via the ''CPUFreq'' subsystem, which defines two layers of abstraction:
 
* [[#Scaling governors|Scaling governors]] implement the algorithms to compute the desired CPU frequency, potentially based off of the system's needs.
* [[#Scaling drivers|Scaling drivers]] interact with the CPU directly, enacting the desired frequencies that the current governor is requesting.
 
A default scaling driver and governor are selected automatically, but userspace tools like [[#cpupower|cpupower]], [[acpid]], [[Laptop Mode Tools]], or GUI tools provided for your desktop environment, may still be used for advanced configuration.


== Userspace tools ==
== Userspace tools ==
Line 29: Line 25:
=== thermald ===
=== thermald ===


{{AUR|thermald}} is a Linux daemon used to prevent the overheating of platforms. This daemon monitors temperature and applies compensation using available cooling methods.
{{Pkg|thermald}} is a [https://01.org/linux-thermal-daemon Linux daemon]{{Dead link|2023|09|16|status=404}} used to prevent the overheating of Intel CPUs. This daemon proactively controls thermal parameters using P-states, T-states, and the Intel power clamp driver. thermald can also be used for older Intel CPUs. If the latest drivers are not available, then the daemon will revert to x86 model specific registers and the Linux "cpufreq subsystem" to control system cooling.
 
By default, it monitors CPU temperature using available CPU digital temperature sensors and maintains CPU temperature under control, before hardware takes aggressive correction action. If there is a skin temperature sensor in thermal sysfs, then it tries to keep skin temperature under 45C.


By default, it monitors CPU temperature using available CPU digital temperature sensors and maintains CPU temperature under control, before HW takes aggressive correction action. If there is a skin temperature sensor in thermal sysfs, then it tries to keep skin temperature under 45C.
On Tiger Lake laptops (e.g. [[Dell Latitude 3420]]), this daemon has been reported as [https://www.phoronix.com/review/intel-thermald-tgl unlocking more performance] than what would be otherwise available.  
 
The associated systemd unit is {{ic|thermald.service}}, which should be [[start]]ed and [[enable]]d.


=== i7z ===
=== i7z ===
{{Pkg|i7z}} is an i7 (and now i3, i5) (CPU) reporting tool for Linux. It can be launched from a Terminal with the command {{ic|i7z}} or as GUI with {{ic|i7z-gui}}.
 
{{Pkg|i7z}} is an i7 (and now i3, i5, i7, i9) CPU reporting tool for Linux. It can be launched from a Terminal with the command {{ic|i7z}} or as GUI with {{ic|i7z-gui}}.
 
=== turbostat ===
 
{{Pkg|turbostat}} can display the frequency, power consumption, idle status and other statistics of the modern Intel and AMD CPUs.


=== cpupower ===
=== cpupower ===
Line 40: Line 45:
{{Pkg|cpupower}} is a set of userspace utilities designed to assist with CPU frequency scaling. The package is not required to use scaling, but is highly recommended because it provides useful command-line utilities and a [[systemd]] service to change the governor at boot.
{{Pkg|cpupower}} is a set of userspace utilities designed to assist with CPU frequency scaling. The package is not required to use scaling, but is highly recommended because it provides useful command-line utilities and a [[systemd]] service to change the governor at boot.


The configuration file for ''cpupower'' is located in {{ic|/etc/default/cpupower}}. This configuration file is read by a bash script in {{ic|/usr/lib/systemd/scripts/cpupower}} which is activated by ''systemd'' with {{ic|cpupower.service}}. You may want to enable {{ic|cpupower.service}} to start at boot.
The configuration file for ''cpupower'' is located in {{ic|/etc/default/cpupower}}. This configuration file is read by a bash script in {{ic|/usr/lib/systemd/scripts/cpupower}} which is activated by ''systemd'' with {{ic|cpupower.service}}. You may want to [[enable]] {{ic|cpupower.service}} to start at boot.
 
=== cpupower-gui ===
 
{{AUR|cpupower-gui-git}} is a graphical utility designed to assist with CPU frequency scaling. The GUI is based on [[GTK]] and is meant to provide the same options as ''cpupower''. ''cpupower-gui'' can enable or disable cores and change the maximum/minimum CPU frequency and governor for each core. The application handles privilege granting through [[polkit]] and allows any logged-in user in the {{ic|wheel}} [[user group]] to change the frequency and governor. See [https://github.com/vagnum08/cpupower-gui?tab=readme-ov-file#systemd-units cpupower-gui systemd units] for more information on {{ic|cpupower-gui.service}} and {{ic|cpupower-gui-user.service}}.
 
=== gnome-shell-extension-cpupower ===
 
{{AUR|gnome-shell-extension-cpupower-git}} is a [[GNOME]] shell extension that can alter minimum/maximum CPU frequencies and enable/disable frequency boosting.
 
=== auto-cpufreq ===
 
{{AUR|auto-cpufreq}} is an automatic CPU speed and power optimizer for Linux based on active monitoring of laptop's battery state, CPU usage, CPU temperature and system load.
 
=== power-profiles-daemon ===
 
The ''powerprofilesctl'' command-line tool from {{Pkg|power-profiles-daemon}} handles power profiles (e.g. balanced, power-saver, performance) through the {{ic|power-profiles-daemon}} service. GNOME and KDE also provide [https://gitlab.freedesktop.org/upower/power-profiles-daemon#how-to-use graphical interfaces] for profile switching; see the following:
 
* [[GNOME#Power modes]]
* [[KDE#Power management]]


== CPU frequency driver ==
See the [https://gitlab.freedesktop.org/upower/power-profiles-daemon#power-profiles-daemon project's README] for more information on usage, use cases, and comparisons with similar projects.
 
[[Start/enable]] the {{ic|power-profiles-daemon}} service. Note that when ''powerprofilesctl'' is launched, it also attempts to start the service (see the [[unit status]] of {{ic|dbus.service}}).
 
{{Note|''power-profiles-daemon'' [https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/blob/main/data/power-profiles-daemon.service.in#L3 conflicts] with other power management services such as [[TLP]], {{AUR|tuned}} and {{AUR|system76-power}}. To use one of the aforementioned services instead without [[uninstall]]ing ''power-profiles-daemon'' (due to its potential status as a dependency), disable the {{ic|power-profiles-daemon}} service by [[mask]]ing it (see also [https://github.com/linrunner/TLP/issues/564], [https://linrunner.de/tlp/installation/arch.html#service-units]).}}
 
== Scaling drivers ==
 
Scaling drivers implement the CPU-specific details of setting frequencies specified by the governor. Strictly speaking, the ACPI standard requires [[wikipedia:Advanced Configuration and Power Interface#Performance state|power-performance states (P-states)]] that start at P0, and becoming decreasingly performant. This functionality is called SpeedStep on Intel, and PowerNow! on AMD.
 
In practice, though, processors provide methods for specifying specific frequencies rather than being restricted to fixed P-states, which the scaling drivers handle.


{{Note|
{{Note|
* The native CPU module is loaded automatically.
* The native CPU module is loaded automatically.
* The {{ic|pstate}} power scaling driver is used automatically for modern Intel CPUs instead of the other drivers below. This driver takes priority over other drivers and is built-in as opposed to being a module. This driver is currently automatically used for Sandy Bridge and newer CPUs. If you encounter a problem while using this driver, add {{ic|intel_pstate=disable}} to your kernel line. You can use the same user space utilities with this driver, '''but cannot control it'''.
* The {{ic|intel_pstate}} CPU power scaling driver is used automatically for modern Intel CPUs instead of the other drivers below. This driver takes priority over other drivers and is built-in as opposed to being a module. This driver is currently automatically used for Sandy Bridge and newer CPUs. {{ic|intel_pstate}} may run in "passive mode" via the {{ic|intel_cpufreq}} driver for older CPUs. If you encounter a problem while using this driver, add {{ic|1=intel_pstate=disable}} to your kernel line in order to revert to using the {{ic|acpi_cpufreq}} driver.
* Even P State behavior mentioned above can be influenced with {{ic|/sys/devices/system/cpu/intel_pstate}}, e.g. Intel Turbo Boost can be deactivated with {{ic|# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo}} for keeping CPU-Temperatures low.
* The {{ic|amd_pstate}} CPU power scaling driver is not active by default, but can be manually enabled when using a supported CPU (Zen 2 and newer) by adding {{ic|1=amd_pstate=passive}}, {{ic|1=amd_pstate=active}} or {{ic|1=amd_pstate=guided}} as a [[kernel parameter]]. Some motherboards might not enable the required setting in their firmware, leading to a {{ic|the _CPC object is not present in SBIOS or ACPI disabled}} error. Change ''Enable CPPC'' , usually found in the ''AMD CBS > NBIO > SMU > CPPC'', from ''Auto'' to ''Enabled'', or any similar settings in your UEFI. If they are not present, consult the vendor website for an update.  
* Additional control for modern Intel CPUs is available with the [https://01.org/linux-thermal-daemon Linux Thermal Daemon] (available as {{AUR|thermald}}), which proactively controls thermal using P-states, T-states, and the Intel power clamp driver. thermald can also be used for older Intel CPUs. If the latest drivers are not available, then the daemon will revert to x86 model specific registers and the Linux ‘cpufreq subsystem’ to control system cooling.
}}
}}


''cpupower'' requires modules to know the limits of the native CPU:
''cpupower'' requires drivers to know the limits of the native CPU:


{| class="wikitable"
{| class="wikitable"
!Module!!Description
! Driver !! Description
|-
|-
| intel_pstate  || This driver implements a scaling driver with an internal governor for Intel Core (Sandy Bridge and newer) processors.
| intel_pstate  || This driver implements a scaling driver with an internal governor for Intel Core (Sandy Bridge and newer) processors.
|-
|-
| acpi-cpufreq || CPUFreq driver which utilizes the ACPI Processor Performance States. This driver also supports the Intel Enhanced SpeedStep (previously supported by the deprecated speedstep-centrino module).
| amd_pstate_epp  || This "active" driver implements a scaling driver with an internal governor for AMD Ryzen (some Zen 2 and newer) processors.
|-
| acpi_cpufreq || CPUFreq driver which utilizes the ACPI Processor Performance States. This driver also supports the Intel Enhanced SpeedStep (previously supported by the deprecated speedstep-centrino module). For AMD Ryzen it only provides 3 frequency states.
|-
| intel_cpufreq || Starting with kernel 5.7, the intel_pstate scaling driver selects "passive mode" aka intel_cpufreq for CPUs that do not support hardware-managed P-states (HWP), i.e. Intel Core i 5th generation or older. This driver acts similar to the ACPI driver on Intel CPUs, except that it does not have the 16-pstate limit of ACPI.
|-
| amd_pstate || This driver exposes way more P-states than acpi_cpufreq does for AMD Ryzen, but does not take over governing.
|-
|-
| speedstep-lib || CPUFreq driver for Intel SpeedStep-enabled processors (mostly Atoms and older Pentiums (< 3))  
| cppc_cpufreq || CPUFreq driver based on ACPI CPPC system (see below). Common default on AArch64 systems. Works on modern x86 too, but the two vendor-specific options above are better.
|-
|-
| powernow-k8  || CPUFreq driver for K8/K10 Athlon 64/Opteron/Phenom processors. Since Linux 3.7 'acpi-cpufreq' will automatically be used for more modern CPUs from this family.
| speedstep_lib || CPUFreq driver for Intel SpeedStep-enabled processors (mostly Atoms and older Pentiums)
|-
|-
| pcc-cpufreq   || This driver supports Processor Clocking Control interface by Hewlett-Packard and Microsoft Corporation which is useful on some ProLiant servers.
| powernow_k8   || CPUFreq driver for K8/K10 Athlon 64/Opteron/Phenom processors. Since Linux 3.7, 'acpi_cpufreq' will automatically be used for more modern AMD CPUs.
|-
|-
| p4-clockmod   || CPUFreq driver for Intel Pentium 4/Xeon/Celeron processors which lowers the CPU temperature by skipping clocks. (You probably want to use a SpeedStep driver instead.)
| pcc_cpufreq  || This driver supports Processor Clocking Control interface by Hewlett-Packard and Microsoft Corporation which is useful on some ProLiant servers.
|-
| p4_clockmod   || CPUFreq driver for Intel Pentium 4/Xeon/Celeron processors which lowers the CPU temperature by skipping clocks. (You probably want to use {{ic|speedstep_lib}} instead.)
|}
|}


Line 79: Line 120:
=== Setting maximum and minimum frequencies ===
=== Setting maximum and minimum frequencies ===


In rare cases, it may be necessary to manually set maximum and minimum frequencies.
In some cases, it may be necessary to manually set maximum and minimum frequencies.


To set the maximum clock frequency (''clock_freq'' is a clock frequency with units: GHz, MHz):
To set the maximum clock frequency ({{ic|''clock_freq''}} is a clock frequency with units: GHz, MHz):


  # cpupower frequency-set -u ''clock_freq''
  # cpupower frequency-set -u ''clock_freq''
Line 97: Line 138:
* The governor, maximum and minimum frequencies can be set in {{ic|/etc/default/cpupower}}.
* The governor, maximum and minimum frequencies can be set in {{ic|/etc/default/cpupower}}.
}}
}}
Alternatively, you can set the frequency manually:
# echo ''value'' | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
The available values can be found in {{ic|/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies}} or similar. [https://web.archive.org/web/20201029114421/https://software.intel.com/sites/default/files/comment/1716807/how-to-change-frequency-on-linux-pub.txt]
=== Configuring frequency boosting ===
Some processors support raising their frequency above the normal maximum for a short burst of time, under appropriate thermal conditions. On Intel processors, this is called [[Wikipedia:Intel Turbo Boost|Turbo Boost]], and on AMD processors this is called [[Wikipedia:AMD Turbo Core|Turbo-Core]].
==== Setting via sysfs (intel_pstate) ====
intel_pstate has a driver-specific interface for prohibiting the processor from entering turbo P-States:
# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
==== Setting via sysfs (other scaling drivers) ====
For scaling drivers other than {{ic|intel_pstate}}, if the driver supports boosting, the {{ic|/sys/devices/system/cpu/cpufreq/boost}} attribute will be present, and can be used to disable/enable boosting.
To disable boosting, run:
# echo 0 > /sys/devices/system/cpu/cpufreq/boost
To enable boosting, run:
# echo 1 > /sys/devices/system/cpu/cpufreq/boost
==== Setting via x86_energy_perf_policy ====
On Intel processors, {{Pkg|x86_energy_perf_policy}} can also be used to configure Turbo Boost:
# x86_energy_perf_policy --turbo-enable 0
=== amd_pstate ===
{{ic|amd_pstate}} has three operation modes: CPPC autonomous (active) mode, CPPC non-autonomous (passive) mode and CPPC guided autonomous (guided) mode. The active/passive/guided mode can be chosen with the [[kernel module parameter]] {{ic|1=amd_pstate=active}},{{ic|1=amd_pstate=passive}} or {{ic|1=amd_pstate=guided}}.
; Active mode
: The {{ic|active}} mode is implemented by {{ic|amd_pstate_epp}} (Energy Performance Preference) driver, available in kernel version 6.3 and later. In this mode, the {{ic|amd_pstate_epp}} driver provides a hint to the hardware when software wants to bias the CPPC firmware towards performance (0x0) or power efficiency (0xff).
; Passive mode
: The {{ic|passive}} mode is implemented by the {{ic|amd_pstate}} driver. In this mode, the driver defines a desired performance based on the current workload, and specifically how much performance degradation can be tolerated without affecting quality of life.
; Guided mode
: The {{ic|guided}} mode is implemented by {{ic|amd_pstate}} driver, available in kernel version 6.4 and later. In this mode, the {{ic|amd_pstate}} driver requests minimum and maximum performance level and the platform autonomously selects a performance level in this range and appropriate to the current workload.


== Scaling governors ==
== Scaling governors ==


{{Note|The modern pstate driver only supports the performance and powersave governors and the performance governor [http://www.phoronix.com/scan.php?page&#61;news_item&px&#61;MTM3NDQ should give better power saving functionality than the old ondemand governor]. }}
Scaling governors are power schemes determining the desired frequency for the CPU. Some request a constant frequency, others implement algorithms to dynamically adjust according to the system load. The governors included in the kernel are:


Governors (see table below) are power schemes for the CPU. Only one may be active at a time. For details, see the [https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt kernel documentation] in the kernel source.
{{Note|1=Each governor is compatible with any scaling driver, with the exceptions of {{ic|intel_pstate}} and {{ic|amd_pstate}} in active mode, which provide pseudo-governors in the form of {{ic|powersave}} and {{ic|performance}}. See [[#Autonomous frequency scaling]] below.}}


{| class="wikitable"
{| class="wikitable"
!Governor!!Description
! Governor !! Description
|-
|-
| ondemand    || Dynamically switch between CPU(s) available if at 95% cpu load
| performance  || Run the CPU at the maximum frequency, obtained from {{ic|/sys/devices/system/cpu/cpu''X''/cpufreq/scaling_max_freq}}.
|-
|-
| performance  || Run the cpu at max frequency
| powersave    || Run the CPU at the minimum frequency, obtained from {{ic|/sys/devices/system/cpu/cpu''X''/cpufreq/scaling_min_freq}}.
|-
|-
| conservative || Dynamically switch between CPU(s) available if at 75% load
| userspace    || Run the CPU at user specified frequencies, configurable via {{ic|/sys/devices/system/cpu/cpu''X''/cpufreq/scaling_setspeed}}.
|-
|-
| powersave    || Run the cpu at the minimum frequency
| ondemand    || Scales the frequency dynamically according to current load. Jumps to the highest frequency and then possibly back off as the idle time increases.
|-
|-
| userspace   || Run the cpu at user specified frequencies
| conservative || Scales the frequency dynamically according to current load. Scales the frequency more gradually than ondemand.
|-
| schedutil   || Scheduler-driven CPU frequency selection [https://lwn.net/Articles/682391/], [https://lore.kernel.org/lkml/1614814.usHvZ58O6A@vostro.rjw.lan/].
|}
|}


Depending on the scaling driver, one of these governors will be loaded by default:
Depending on the scaling driver, one of these governors will be loaded by default:
* {{ic|ondemand}} for AMD and older Intel CPU.
 
* {{ic|powersave}} for Intel Sandy Bridge and newer CPU.
* {{ic|schedutil}} since [https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commit/83345a2f829af62ce6fd4b4fa3a875b8f6560f43 Linux 4.9.5]
* the internal {{ic|powersave}} governor for Intel CPUs using the {{ic|intel_pstate}} driver (see the note above, it is equivalent to {{ic|schedutil}}).
 
{{Warning|Use CPU monitoring tools (for temperatures, voltage, etc.) when changing the default governor.}}


To activate a particular governor, run:
To activate a particular governor, run:
Line 132: Line 220:


Alternatively, you can activate a governor on every available CPU manually:
Alternatively, you can activate a governor on every available CPU manually:
  # echo ''governor'' | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null
 
  # echo ''governor'' | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor


{{Tip|To monitor cpu speed in real time, run:
{{Tip|To monitor cpu speed in real time, run:
  $ watch grep \"cpu MHz\" /proc/cpuinfo
 
  $ watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq
 
}}
}}


=== Tuning the ondemand governor ===
=== Tuning the ondemand governor ===


See the [https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt kernel documentation] for details.
See the [https://docs.kernel.org/admin-guide/pm/cpufreq.html#ondemand kernel documentation] for details.


==== Switching threshold ====
==== Switching threshold ====
Line 146: Line 237:
To set the threshold for stepping up to another frequency:
To set the threshold for stepping up to another frequency:


  # echo -n ''percent'' > /sys/devices/system/cpu/cpufreq/<governor>/up_threshold
  # echo -n ''percent'' > /sys/devices/system/cpu/cpufreq/''governor''/up_threshold


To set the threshold for stepping down to another frequency:
To set the threshold for stepping down to another frequency:


  # echo -n ''percent'' > /sys/devices/system/cpu/cpufreq/<governor>/down_threshold
  # echo -n ''percent'' > /sys/devices/system/cpu/cpufreq/''governor''/down_threshold


==== Sampling rate ====
==== Sampling rate ====


The sampling rate determines how frequently the governor checks to tune the CPU. {{ic|sampling_down_factor}} is a tunable that multiplies the sampling rate when the CPU is at its highest clock frequency thereby delaying load evaluation and improving performance. Allowed values for {{ic|sampling_down_factor}} are 1 to 100000.  This tunable has no effect on behavior at lower CPU frequencies/loads.
The sampling rate determines how frequently the governor checks to tune the CPU. {{ic|sampling_down_factor}} is a tunable that multiplies the sampling rate when the CPU is at its highest clock frequency, thereby delaying load evaluation and improving performance. Allowed values for {{ic|sampling_down_factor}} are 1 to 100000.  This tunable has no effect on behavior at lower CPU frequencies/loads.


To read the value (default = 1), run:
To read the value (default = 1), run:
Line 166: Line 257:
==== Make changes permanent ====
==== Make changes permanent ====


To have changes persist on system reboot probably the easiest is to use systemd-tmpfiles. For example to set the sampling_down_factor on boot you could create or edit a {{ic|/etc/tmpfiles.d/10-cpu-sampling-down.conf}} file as follow
Since Linux 5.9, it is possible to set the {{ic|cpufreq.default_governor}} kernel option.[https://kernelnewbies.org/Linux_5.9#CPU_Frequency_scaling] To set the desired scaling parameters at boot, configure the [[#cpupower|cpupower]] utility and enable its systemd service. Alternatively, [[systemd-tmpfiles]] or [[udev]] rules can be used.
 
== Autonomous frequency scaling ==
 
Both Intel and AMD define a way to have the CPU decide its own speed based on (1) a performance range from the system and (2) a performance/power hint specifying the preference. The fully-autonomous mode is activated when:


{{hc|/etc/tmpfiles.d/10-cpu-sampling-down.conf|<nowiki>
* {{ic|amd-pstate}} is set to "active"—requires manual configuration and CPPC support in both the CPU ''and'' BIOS,
w /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor - - - - 40
* {{ic|intel-pstate}} is set to "active" ''and'' hardware P-state (HWP) is available (i.e. Sandy Bridge and newer)—works out-of-the-box.
</nowiki>}}
 
The most important feature of active governing is that only two governors appear available, {{ic|powersave}} and {{ic|performance}}. They do not work ''at all'' like their normal counterpart, however: these levels are translated into an ''Energy Performance Preference'' hint for the CPU's internal governor. As a result, they both provide dynamic scaling, similar to the {{ic|schedutil}} or {{ic|ondemand}} generic governors respectively, differing mostly in latency. The {{ic|performance}} algorithm [https://www.phoronix.com/scan.php?page=news_item&px=MTM3NDQ should give better power saving functionality than the old ondemand governor] for Intel HWP.
 
=== Intel active, non-HWP ===
 
The intel-pstate driver has, confusingly, an "active" mode that works without the CPU's active decision. This mode turns on when kernel cmdline forces an "active" mode but HWP is unavailable or disabled. It will still only provide {{ic|powersave}} and {{ic|performance}}, but the driver itself does the governing in a way similar to {{ic|schedutil}} and {{ic|performance}} (i.e. it stays at the maximum P-state). There is no real benefit to this mode compared to passive intel-pstate.
 
=== Setting the EPP ===
 
It is possible to select in-between hints with the sysfs interfaces available. The interface is identical between AMD and Intel, where the files {{ic|/sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference}} describe the current preference and {{ic|/sys/devices/system/cpu/cpu*/cpufreq/energy_performance_available_preferences}} providing a list of available preferences. One can also pass a number between 0 (favor performance) and 255 (favor power). A fallback implementation is provided for Intel CPUs without EPP, translating strings to EPB levels (described in next section) but failing on numbers.
 
{{Pkg|x86_energy_perf_policy}} supports configuration of EPP hints via the {{ic|--hwp-epp}} switch on Intel CPUs ''only''. It works via direct access of machine-specific registers (MSRs) which differ between Intel and AMD. The program can also restrict the range of HWP frequencies using a range of frequency multipliers.
 
To enable hardware P-States with {{man|8|x86_energy_perf_policy}}:
 
# x86_energy_perf_policy -H 1
# x86_energy_perf_policy -U 1
 
== Collaborative processor performance control ==
 
The power consumption of modern CPUs is no longer simply dependent on the frequency or voltage setting, as there are modules that can be switched on as needed. Collaborative processor performance control (CPPC) is the P-state replacement provided by ACPI 5.0. Instead of defining a table of static frequency levels, the processor provides many abstract ''performance levels'' and the operating system selects from these levels. There are two advantages:
 
* There is no longer a limit of 16 P-state entries; a typical CPU provides hundreds of levels to choose from.
* The CPU can provide a higher frequency (e.g. boost) for a performance level when certain parts (e.g. vector FPU) is not used.
 
On the other hand, the flexible frequency breaks frequency-invariant utilization tracking, which is important for fast frequency changes by {{ic|schedutil}}. A number of vendor-specific methods have been used to make the frequency static under CPPC, with most successes coming from arm64.
 
{{ic|cppc_cpufreq}} is the generic CPPC scaling driver. {{ic|amd_pstate}} also uses ACPI CPPC to manage the CPU frequency when the Zen 3 MSR is unavailable – this method, also called "shared memory", has higher latency than MSR.
 
== Intel performance and energy bias hint ==
 
The [https://docs.kernel.org/admin-guide/pm/intel_epb.html Intel performance and energy bias hint (EPB)] is an interface provided by Intel CPUs to allow for user space to specify the desired power-performance tradeoff, on a scale of 0 (highest performance) to 15 (highest energy savings). The EPB register is another layer of performance management functioning independently from frequency scaling. It influences how aggressive P-state and C-state selection will be, and informs internal model-specific decision making that affects energy consumption.
 
Common values and their aliases, as recognized by sysfs and {{man|8|x86_energy_perf_policy}} are:
 
{| class="wikitable"
! EPB value
! String
|-
| 0
| performance
|-
| 4
| balance-performance
|-
| 6
| normal, default
|-
| 8
| balance-power
|-
| 15
| power
|}
 
=== Setting via sysfs ===
 
The EPB can be set using a sysfs attribute:
 
# echo ''epb'' | tee /sys/devices/system/cpu/cpu*/power/energy_perf_bias
 
=== Setting via x86_energy_perf_policy ===
 
With {{Pkg|x86_energy_perf_policy}}:
 
# x86_energy_perf_policy --epb ''epb''
 
=== Setting via cpupower ===
 
With {{Pkg|cpupower}}:
 
# cpupower set -b ''epb_value''
 
{{Warning|cpupower does not support the string aliases. If given a string, it will silently set the EPB to 0, corresponding to max performance.}}


== Interaction with ACPI events ==
== Interaction with ACPI events ==


Users may configure scaling governors to switch automatically based on different ACPI events such as connecting the AC adapter or closing a laptop lid. A quick example is given below, however it may be worth reading full article on [[acpid]].
Users may configure scaling governors to switch automatically based on different ACPI events such as connecting the AC adapter or closing a laptop lid. A quick example is given below; however, it may be worth reading full article on [[acpid]].


Events are defined in {{ic|/etc/acpi/handler.sh}}. If the {{Pkg|acpid}} package is installed, the file should already exist and be executable. For example, to change the scaling governor from {{ic|performance}} to {{ic|conservative}} when the AC adapter is disconnected and change it back if reconnected:
Events are defined in {{ic|/etc/acpi/handler.sh}}. If the {{Pkg|acpid}} package is installed, the file should already exist and be executable. For example, to change the scaling governor from {{ic|performance}} to {{ic|conservative}} when the AC adapter is disconnected and change it back if reconnected:
Line 203: Line 371:
[...]
[...]
</nowiki>}}
</nowiki>}}
== Privilege granting under GNOME ==
{{Out of date|See the note below.}}
{{Note|systemd introduced logind which handles consolekit and policykit actions. The following code below does not work. With logind, simply edit in the file {{ic|/usr/share/polkit-1/actions/org.gnome.cpufreqselector.policy}} the <defaults> elements according to your needs and the polkit manual [http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html].}}
[[GNOME]] has a nice applet to change the governor on the fly. To use it without the need to enter the root password, simply create following file:
{{hc|/var/lib/polkit-1/localauthority/50-local.d/org.gnome.cpufreqselector.pkla|2=
[org.gnome.cpufreqselector]
Identity=unix-user:''user''
Action=org.gnome.cpufreqselector
ResultAny=no
ResultInactive=no
ResultActive=yes
}}
Where the word ''user'' is replaced with the username of interest.
The {{AUR|desktop-privileges}} package in the [[AUR]] contains a similar {{ic|.pkla}} file for authorizing all users of the {{ic|power}} [[group]] to change the governor.


== Troubleshooting ==
== Troubleshooting ==
{{Accuracy}}
* Some applications, like [[ntop]], do not respond well to automatic frequency scaling. In the case of ntop it can result in segmentation faults and lots of lost information as even the {{ic|on-demand}} governor cannot change the frequency quickly enough when a lot of packets suddenly arrive at the monitored network interface that cannot be handled by the current processor speed.
* Some CPU's may suffer from poor performance with the default settings of the {{ic|on-demand}} governor (e.g. flash videos not playing smoothly or stuttering window animations). Instead of completely disabling frequency scaling to resolve these issues, the aggressiveness of frequency scaling can be increased by lowering the ''up_threshold'' [[sysctl]] variable for each CPU. See [[#Switching_threshold|how to change the on-demand governor's threshold]].
* Sometimes the on-demand governor may not throttle to the maximum frequency but one step below. This can be solved by setting max_freq value slightly higher than the real maximum. For example, if frequency range of the CPU is from 2.00 GHz to 3.00 GHz, setting max_freq to 3.01 GHz can be a good idea.
* Some combinations of [[ALSA]] drivers and sound chips may cause audio skipping as the governor changes between frequencies, switching back to a non-changing governor seems to stop the audio skipping.


=== BIOS frequency limitation ===
=== BIOS frequency limitation ===
Line 241: Line 378:
Some CPU/BIOS configurations may have difficulties to scale to the maximum frequency or scale to higher frequencies at all. This is most likely caused by BIOS events telling the OS to limit the frequency resulting in {{ic|/sys/devices/system/cpu/cpu0/cpufreq/bios_limit}} set to a lower value.
Some CPU/BIOS configurations may have difficulties to scale to the maximum frequency or scale to higher frequencies at all. This is most likely caused by BIOS events telling the OS to limit the frequency resulting in {{ic|/sys/devices/system/cpu/cpu0/cpufreq/bios_limit}} set to a lower value.


Either you just made a specific Setting in the BIOS Setup Utility, (Frequency, Thermal Management, etc.) you can blame a buggy/outdated BIOS or the BIOS might have a serious reason for throttling the CPU on it's own.
Either you just made a specific Setting in the BIOS Setup Utility, (Frequency, Thermal Management, etc.) you can blame a buggy/outdated BIOS or the BIOS might have a serious reason for throttling the CPU on its own.


Reasons like that can be (assuming your machine's a notebook) that the battery is removed (or near death) so you're on AC-power only. In this case a weak AC-source might not supply enough electricity to fulfill extreme peak demands by the overall system and as there is no battery to assist this could lead to data loss, data corruption or in worst case even hardware damage!
Reasons like that can be (assuming your machine's a notebook) that the battery is removed (or near death) so you are on AC-power only. In this case, a weak AC-source might not supply enough electricity to fulfill extreme peak demands by the overall system and as there is no battery to assist this could lead to data loss, data corruption or in worst case even hardware damage!


Not all BIOS'es limit the CPU-Frequency in this case, but for example most IBM/Lenovo Thinkpads do. Refer to thinkwiki for more [http://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling thinkpad related info on this topic].
Not all BIOS'es limit the CPU-Frequency in this case, but, for example, most IBM/Lenovo Thinkpads do. Refer to thinkwiki for more [https://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling thinkpad related info on this topic].


If you checked there's not just an odd BIOS setting and you know what you're doing you can make the Kernel ignore these BIOS-limitations.
If you checked there is not just an odd BIOS setting and you know what you are doing, you can make the Kernel ignore these BIOS-limitations.


{{Warning|Make sure you read and understood the section above. CPU frequency limitation is a safety feature of your BIOS and you should not need to work around it.}}
{{Warning|Make sure you read and understood the section above. CPU frequency limitation is a safety feature of your BIOS and you should not need to work around it.}}


A special parameter has to be passed to the processor module.
Set the {{ic|1=ignore_ppc=1}} [[kernel module parameter]] for the {{ic|processor}} module. For trying this temporarily, change the value in {{ic|/sys/module/processor/parameters/ignore_ppc}} from {{ic|0}} to {{ic|1}}.
 
For trying this temporarily change the value in {{ic|/sys/module/processor/parameters/ignore_ppc}} from {{ic|0}} to {{ic|1}}.
 
For setting it permanent refer to [[Kernel_modules#Configuration|Kernel modules]] or just read on.
Add {{ic|1=processor.ignore_ppc=1}} to your kernel boot line or create
{{hc|/etc/modprobe.d/ignore_ppc.conf|2=# If the frequency of your machine gets wrongly limited by BIOS, this should help
options processor ignore_ppc=1}}
 
== Common issues ==


=== High load ===
Some systems use another mechanism to limit the CPU frequency, e.g., when running without battery or an unofficial power adapter. See [[Lenovo ThinkPad T480#CPU stuck at minimum frequency]] for a way to manipulate the BD PROCHOT bit in Intel CPUs and [[Dell XPS 15 (9560)#General slowness & stuttering]] for alternative fixes. It does not only apply to the Lenovo ThinkPad T480, but is a common problem in Dell XPS models like the XPS15 9550 and XPS15 9560, too. The bit also is what makes at least some Intel-based MacBooks run with minimum CPU frequency when no battery is connected.


{{Expansion|What kernel version? Needs a link to an open bug report, all that I've been able to find with a quick search is [https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1413149].}}
{{Warning|Please note that this is '''not''' recommended and can seriously damage your mac. Do at your own risk. [https://github.com/syscl/CPUTune]}}
 
There is a bug in the kernel module {{ic|rtsx_usb_ms}} which causes a constant load over 1.0. Test whether it makes a difference by temporarily removing it {{ic|rmmod rtsx_usb_ms}}


== See also ==
== See also ==
 
* [https://docs.kernel.org/cpu-freq/index.html Linux CPUFreq - kernel documentation]
* [https://www.kernel.org/doc/Documentation/cpu-freq/index.txt Linux CPUFreq - kernel documentation]
* [https://www.reddit.com/r/linux/comments/1hdogn/acpi_cpufreq_or_intel_pstates/ Reddit post talking about pstate]
* [http://www.reddit.com/r/linux/comments/1hdogn/acpi_cpufreq_or_intel_pstates/ Comprehensive explanation of pstate]
* [https://docs.kernel.org/admin-guide/pm/cpufreq.html#frequency-boost-support Processor boosting control]
* [https://docs.kernel.org/admin-guide/pm/intel_pstate.html intel_pstate kernel documentation]
* [https://docs.kernel.org/admin-guide/pm/amd-pstate.html amd-pstate kernel documentation]
* [https://linrunner.de/tlp/settings/processor.html intel_pstate/intel_cpufreq documentation kernel 5.7+]

Latest revision as of 02:21, 21 March 2024

CPU performance scaling enables the operating system to scale the CPU frequency up or down in order to save power or improve performance. Scaling can be done automatically in response to system load, adjust itself in response to ACPI events, or be manually changed by user space programs.

The Linux kernel offers CPU performance scaling via the CPUFreq subsystem, which defines two layers of abstraction:

  • Scaling governors implement the algorithms to compute the desired CPU frequency, potentially based off of the system's needs.
  • Scaling drivers interact with the CPU directly, enacting the desired frequencies that the current governor is requesting.

A default scaling driver and governor are selected automatically, but userspace tools like cpupower, acpid, Laptop Mode Tools, or GUI tools provided for your desktop environment, may still be used for advanced configuration.

Userspace tools

thermald

thermald is a Linux daemon[dead link 2023-09-16 ⓘ] used to prevent the overheating of Intel CPUs. This daemon proactively controls thermal parameters using P-states, T-states, and the Intel power clamp driver. thermald can also be used for older Intel CPUs. If the latest drivers are not available, then the daemon will revert to x86 model specific registers and the Linux "cpufreq subsystem" to control system cooling.

By default, it monitors CPU temperature using available CPU digital temperature sensors and maintains CPU temperature under control, before hardware takes aggressive correction action. If there is a skin temperature sensor in thermal sysfs, then it tries to keep skin temperature under 45C.

On Tiger Lake laptops (e.g. Dell Latitude 3420), this daemon has been reported as unlocking more performance than what would be otherwise available.

The associated systemd unit is thermald.service, which should be started and enabled.

i7z

i7z is an i7 (and now i3, i5, i7, i9) CPU reporting tool for Linux. It can be launched from a Terminal with the command i7z or as GUI with i7z-gui.

turbostat

turbostat can display the frequency, power consumption, idle status and other statistics of the modern Intel and AMD CPUs.

cpupower

cpupower is a set of userspace utilities designed to assist with CPU frequency scaling. The package is not required to use scaling, but is highly recommended because it provides useful command-line utilities and a systemd service to change the governor at boot.

The configuration file for cpupower is located in /etc/default/cpupower. This configuration file is read by a bash script in /usr/lib/systemd/scripts/cpupower which is activated by systemd with cpupower.service. You may want to enable cpupower.service to start at boot.

cpupower-gui

cpupower-gui-gitAUR is a graphical utility designed to assist with CPU frequency scaling. The GUI is based on GTK and is meant to provide the same options as cpupower. cpupower-gui can enable or disable cores and change the maximum/minimum CPU frequency and governor for each core. The application handles privilege granting through polkit and allows any logged-in user in the wheel user group to change the frequency and governor. See cpupower-gui systemd units for more information on cpupower-gui.service and cpupower-gui-user.service.

gnome-shell-extension-cpupower

gnome-shell-extension-cpupower-gitAUR is a GNOME shell extension that can alter minimum/maximum CPU frequencies and enable/disable frequency boosting.

auto-cpufreq

auto-cpufreqAUR is an automatic CPU speed and power optimizer for Linux based on active monitoring of laptop's battery state, CPU usage, CPU temperature and system load.

power-profiles-daemon

The powerprofilesctl command-line tool from power-profiles-daemon handles power profiles (e.g. balanced, power-saver, performance) through the power-profiles-daemon service. GNOME and KDE also provide graphical interfaces for profile switching; see the following:

See the project's README for more information on usage, use cases, and comparisons with similar projects.

Start/enable the power-profiles-daemon service. Note that when powerprofilesctl is launched, it also attempts to start the service (see the unit status of dbus.service).

Note: power-profiles-daemon conflicts with other power management services such as TLP, tunedAUR and system76-powerAUR. To use one of the aforementioned services instead without uninstalling power-profiles-daemon (due to its potential status as a dependency), disable the power-profiles-daemon service by masking it (see also [1], [2]).

Scaling drivers

Scaling drivers implement the CPU-specific details of setting frequencies specified by the governor. Strictly speaking, the ACPI standard requires power-performance states (P-states) that start at P0, and becoming decreasingly performant. This functionality is called SpeedStep on Intel, and PowerNow! on AMD.

In practice, though, processors provide methods for specifying specific frequencies rather than being restricted to fixed P-states, which the scaling drivers handle.

Note:
  • The native CPU module is loaded automatically.
  • The intel_pstate CPU power scaling driver is used automatically for modern Intel CPUs instead of the other drivers below. This driver takes priority over other drivers and is built-in as opposed to being a module. This driver is currently automatically used for Sandy Bridge and newer CPUs. intel_pstate may run in "passive mode" via the intel_cpufreq driver for older CPUs. If you encounter a problem while using this driver, add intel_pstate=disable to your kernel line in order to revert to using the acpi_cpufreq driver.
  • The amd_pstate CPU power scaling driver is not active by default, but can be manually enabled when using a supported CPU (Zen 2 and newer) by adding amd_pstate=passive, amd_pstate=active or amd_pstate=guided as a kernel parameter. Some motherboards might not enable the required setting in their firmware, leading to a the _CPC object is not present in SBIOS or ACPI disabled error. Change Enable CPPC , usually found in the AMD CBS > NBIO > SMU > CPPC, from Auto to Enabled, or any similar settings in your UEFI. If they are not present, consult the vendor website for an update.

cpupower requires drivers to know the limits of the native CPU:

Driver Description
intel_pstate This driver implements a scaling driver with an internal governor for Intel Core (Sandy Bridge and newer) processors.
amd_pstate_epp This "active" driver implements a scaling driver with an internal governor for AMD Ryzen (some Zen 2 and newer) processors.
acpi_cpufreq CPUFreq driver which utilizes the ACPI Processor Performance States. This driver also supports the Intel Enhanced SpeedStep (previously supported by the deprecated speedstep-centrino module). For AMD Ryzen it only provides 3 frequency states.
intel_cpufreq Starting with kernel 5.7, the intel_pstate scaling driver selects "passive mode" aka intel_cpufreq for CPUs that do not support hardware-managed P-states (HWP), i.e. Intel Core i 5th generation or older. This driver acts similar to the ACPI driver on Intel CPUs, except that it does not have the 16-pstate limit of ACPI.
amd_pstate This driver exposes way more P-states than acpi_cpufreq does for AMD Ryzen, but does not take over governing.
cppc_cpufreq CPUFreq driver based on ACPI CPPC system (see below). Common default on AArch64 systems. Works on modern x86 too, but the two vendor-specific options above are better.
speedstep_lib CPUFreq driver for Intel SpeedStep-enabled processors (mostly Atoms and older Pentiums)
powernow_k8 CPUFreq driver for K8/K10 Athlon 64/Opteron/Phenom processors. Since Linux 3.7, 'acpi_cpufreq' will automatically be used for more modern AMD CPUs.
pcc_cpufreq This driver supports Processor Clocking Control interface by Hewlett-Packard and Microsoft Corporation which is useful on some ProLiant servers.
p4_clockmod CPUFreq driver for Intel Pentium 4/Xeon/Celeron processors which lowers the CPU temperature by skipping clocks. (You probably want to use speedstep_lib instead.)

To see a full list of available modules, run:

$ ls /usr/lib/modules/$(uname -r)/kernel/drivers/cpufreq/

Load the appropriate module (see Kernel modules for details). Once the appropriate cpufreq driver is loaded, detailed information about the CPU(s) can be displayed by running

$ cpupower frequency-info

Setting maximum and minimum frequencies

In some cases, it may be necessary to manually set maximum and minimum frequencies.

To set the maximum clock frequency (clock_freq is a clock frequency with units: GHz, MHz):

# cpupower frequency-set -u clock_freq

To set the minimum clock frequency:

# cpupower frequency-set -d clock_freq

To set the CPU to run at a specified frequency:

# cpupower frequency-set -f clock_freq
Note:
  • To adjust for only a single CPU core, append -c core_number.
  • The governor, maximum and minimum frequencies can be set in /etc/default/cpupower.

Alternatively, you can set the frequency manually:

# echo value | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq

The available values can be found in /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies or similar. [3]

Configuring frequency boosting

Some processors support raising their frequency above the normal maximum for a short burst of time, under appropriate thermal conditions. On Intel processors, this is called Turbo Boost, and on AMD processors this is called Turbo-Core.

Setting via sysfs (intel_pstate)

intel_pstate has a driver-specific interface for prohibiting the processor from entering turbo P-States:

# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo

Setting via sysfs (other scaling drivers)

For scaling drivers other than intel_pstate, if the driver supports boosting, the /sys/devices/system/cpu/cpufreq/boost attribute will be present, and can be used to disable/enable boosting.

To disable boosting, run:

# echo 0 > /sys/devices/system/cpu/cpufreq/boost

To enable boosting, run:

# echo 1 > /sys/devices/system/cpu/cpufreq/boost

Setting via x86_energy_perf_policy

On Intel processors, x86_energy_perf_policy can also be used to configure Turbo Boost:

# x86_energy_perf_policy --turbo-enable 0

amd_pstate

amd_pstate has three operation modes: CPPC autonomous (active) mode, CPPC non-autonomous (passive) mode and CPPC guided autonomous (guided) mode. The active/passive/guided mode can be chosen with the kernel module parameter amd_pstate=active,amd_pstate=passive or amd_pstate=guided.

Active mode
The active mode is implemented by amd_pstate_epp (Energy Performance Preference) driver, available in kernel version 6.3 and later. In this mode, the amd_pstate_epp driver provides a hint to the hardware when software wants to bias the CPPC firmware towards performance (0x0) or power efficiency (0xff).
Passive mode
The passive mode is implemented by the amd_pstate driver. In this mode, the driver defines a desired performance based on the current workload, and specifically how much performance degradation can be tolerated without affecting quality of life.
Guided mode
The guided mode is implemented by amd_pstate driver, available in kernel version 6.4 and later. In this mode, the amd_pstate driver requests minimum and maximum performance level and the platform autonomously selects a performance level in this range and appropriate to the current workload.

Scaling governors

Scaling governors are power schemes determining the desired frequency for the CPU. Some request a constant frequency, others implement algorithms to dynamically adjust according to the system load. The governors included in the kernel are:

Note: Each governor is compatible with any scaling driver, with the exceptions of intel_pstate and amd_pstate in active mode, which provide pseudo-governors in the form of powersave and performance. See #Autonomous frequency scaling below.
Governor Description
performance Run the CPU at the maximum frequency, obtained from /sys/devices/system/cpu/cpuX/cpufreq/scaling_max_freq.
powersave Run the CPU at the minimum frequency, obtained from /sys/devices/system/cpu/cpuX/cpufreq/scaling_min_freq.
userspace Run the CPU at user specified frequencies, configurable via /sys/devices/system/cpu/cpuX/cpufreq/scaling_setspeed.
ondemand Scales the frequency dynamically according to current load. Jumps to the highest frequency and then possibly back off as the idle time increases.
conservative Scales the frequency dynamically according to current load. Scales the frequency more gradually than ondemand.
schedutil Scheduler-driven CPU frequency selection [4], [5].

Depending on the scaling driver, one of these governors will be loaded by default:

  • schedutil since Linux 4.9.5
  • the internal powersave governor for Intel CPUs using the intel_pstate driver (see the note above, it is equivalent to schedutil).
Warning: Use CPU monitoring tools (for temperatures, voltage, etc.) when changing the default governor.

To activate a particular governor, run:

# cpupower frequency-set -g governor
Note:
  • To adjust for only a single CPU core, append -c core_number to the command above.
  • Activating a governor requires that specific kernel module (named cpufreq_governor) is loaded. As of kernel 3.4, these modules are loaded automatically.

Alternatively, you can activate a governor on every available CPU manually:

# echo governor | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
Tip: To monitor cpu speed in real time, run:
$ watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq

Tuning the ondemand governor

See the kernel documentation for details.

Switching threshold

To set the threshold for stepping up to another frequency:

# echo -n percent > /sys/devices/system/cpu/cpufreq/governor/up_threshold

To set the threshold for stepping down to another frequency:

# echo -n percent > /sys/devices/system/cpu/cpufreq/governor/down_threshold

Sampling rate

The sampling rate determines how frequently the governor checks to tune the CPU. sampling_down_factor is a tunable that multiplies the sampling rate when the CPU is at its highest clock frequency, thereby delaying load evaluation and improving performance. Allowed values for sampling_down_factor are 1 to 100000. This tunable has no effect on behavior at lower CPU frequencies/loads.

To read the value (default = 1), run:

$ cat /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

To set the value, run:

# echo -n value > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

Make changes permanent

Since Linux 5.9, it is possible to set the cpufreq.default_governor kernel option.[6] To set the desired scaling parameters at boot, configure the cpupower utility and enable its systemd service. Alternatively, systemd-tmpfiles or udev rules can be used.

Autonomous frequency scaling

Both Intel and AMD define a way to have the CPU decide its own speed based on (1) a performance range from the system and (2) a performance/power hint specifying the preference. The fully-autonomous mode is activated when:

  • amd-pstate is set to "active"—requires manual configuration and CPPC support in both the CPU and BIOS,
  • intel-pstate is set to "active" and hardware P-state (HWP) is available (i.e. Sandy Bridge and newer)—works out-of-the-box.

The most important feature of active governing is that only two governors appear available, powersave and performance. They do not work at all like their normal counterpart, however: these levels are translated into an Energy Performance Preference hint for the CPU's internal governor. As a result, they both provide dynamic scaling, similar to the schedutil or ondemand generic governors respectively, differing mostly in latency. The performance algorithm should give better power saving functionality than the old ondemand governor for Intel HWP.

Intel active, non-HWP

The intel-pstate driver has, confusingly, an "active" mode that works without the CPU's active decision. This mode turns on when kernel cmdline forces an "active" mode but HWP is unavailable or disabled. It will still only provide powersave and performance, but the driver itself does the governing in a way similar to schedutil and performance (i.e. it stays at the maximum P-state). There is no real benefit to this mode compared to passive intel-pstate.

Setting the EPP

It is possible to select in-between hints with the sysfs interfaces available. The interface is identical between AMD and Intel, where the files /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference describe the current preference and /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_available_preferences providing a list of available preferences. One can also pass a number between 0 (favor performance) and 255 (favor power). A fallback implementation is provided for Intel CPUs without EPP, translating strings to EPB levels (described in next section) but failing on numbers.

x86_energy_perf_policy supports configuration of EPP hints via the --hwp-epp switch on Intel CPUs only. It works via direct access of machine-specific registers (MSRs) which differ between Intel and AMD. The program can also restrict the range of HWP frequencies using a range of frequency multipliers.

To enable hardware P-States with x86_energy_perf_policy(8):

# x86_energy_perf_policy -H 1
# x86_energy_perf_policy -U 1

Collaborative processor performance control

The power consumption of modern CPUs is no longer simply dependent on the frequency or voltage setting, as there are modules that can be switched on as needed. Collaborative processor performance control (CPPC) is the P-state replacement provided by ACPI 5.0. Instead of defining a table of static frequency levels, the processor provides many abstract performance levels and the operating system selects from these levels. There are two advantages:

  • There is no longer a limit of 16 P-state entries; a typical CPU provides hundreds of levels to choose from.
  • The CPU can provide a higher frequency (e.g. boost) for a performance level when certain parts (e.g. vector FPU) is not used.

On the other hand, the flexible frequency breaks frequency-invariant utilization tracking, which is important for fast frequency changes by schedutil. A number of vendor-specific methods have been used to make the frequency static under CPPC, with most successes coming from arm64.

cppc_cpufreq is the generic CPPC scaling driver. amd_pstate also uses ACPI CPPC to manage the CPU frequency when the Zen 3 MSR is unavailable – this method, also called "shared memory", has higher latency than MSR.

Intel performance and energy bias hint

The Intel performance and energy bias hint (EPB) is an interface provided by Intel CPUs to allow for user space to specify the desired power-performance tradeoff, on a scale of 0 (highest performance) to 15 (highest energy savings). The EPB register is another layer of performance management functioning independently from frequency scaling. It influences how aggressive P-state and C-state selection will be, and informs internal model-specific decision making that affects energy consumption.

Common values and their aliases, as recognized by sysfs and x86_energy_perf_policy(8) are:

EPB value String
0 performance
4 balance-performance
6 normal, default
8 balance-power
15 power

Setting via sysfs

The EPB can be set using a sysfs attribute:

# echo epb | tee /sys/devices/system/cpu/cpu*/power/energy_perf_bias

Setting via x86_energy_perf_policy

With x86_energy_perf_policy:

# x86_energy_perf_policy --epb epb

Setting via cpupower

With cpupower:

# cpupower set -b epb_value
Warning: cpupower does not support the string aliases. If given a string, it will silently set the EPB to 0, corresponding to max performance.

Interaction with ACPI events

Users may configure scaling governors to switch automatically based on different ACPI events such as connecting the AC adapter or closing a laptop lid. A quick example is given below; however, it may be worth reading full article on acpid.

Events are defined in /etc/acpi/handler.sh. If the acpid package is installed, the file should already exist and be executable. For example, to change the scaling governor from performance to conservative when the AC adapter is disconnected and change it back if reconnected:

/etc/acpi/handler.sh
[...]

ac_adapter)
    case "$2" in
        AC*)
            case "$4" in
                00000000)
                    echo "conservative" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor    
                    echo -n $minspeed >$setspeed
                    #/etc/laptop-mode/laptop-mode start
                ;;
                00000001)
                    echo "performance" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
                    echo -n $maxspeed >$setspeed
                    #/etc/laptop-mode/laptop-mode stop
                ;;
            esac
        ;;
        *) logger "ACPI action undefined: $2" ;;
    esac
;;

[...]

Troubleshooting

BIOS frequency limitation

Some CPU/BIOS configurations may have difficulties to scale to the maximum frequency or scale to higher frequencies at all. This is most likely caused by BIOS events telling the OS to limit the frequency resulting in /sys/devices/system/cpu/cpu0/cpufreq/bios_limit set to a lower value.

Either you just made a specific Setting in the BIOS Setup Utility, (Frequency, Thermal Management, etc.) you can blame a buggy/outdated BIOS or the BIOS might have a serious reason for throttling the CPU on its own.

Reasons like that can be (assuming your machine's a notebook) that the battery is removed (or near death) so you are on AC-power only. In this case, a weak AC-source might not supply enough electricity to fulfill extreme peak demands by the overall system and as there is no battery to assist this could lead to data loss, data corruption or in worst case even hardware damage!

Not all BIOS'es limit the CPU-Frequency in this case, but, for example, most IBM/Lenovo Thinkpads do. Refer to thinkwiki for more thinkpad related info on this topic.

If you checked there is not just an odd BIOS setting and you know what you are doing, you can make the Kernel ignore these BIOS-limitations.

Warning: Make sure you read and understood the section above. CPU frequency limitation is a safety feature of your BIOS and you should not need to work around it.

Set the ignore_ppc=1 kernel module parameter for the processor module. For trying this temporarily, change the value in /sys/module/processor/parameters/ignore_ppc from 0 to 1.

Some systems use another mechanism to limit the CPU frequency, e.g., when running without battery or an unofficial power adapter. See Lenovo ThinkPad T480#CPU stuck at minimum frequency for a way to manipulate the BD PROCHOT bit in Intel CPUs and Dell XPS 15 (9560)#General slowness & stuttering for alternative fixes. It does not only apply to the Lenovo ThinkPad T480, but is a common problem in Dell XPS models like the XPS15 9550 and XPS15 9560, too. The bit also is what makes at least some Intel-based MacBooks run with minimum CPU frequency when no battery is connected.

Warning: Please note that this is not recommended and can seriously damage your mac. Do at your own risk. [7]

See also