CPU frequency scaling
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.
thermald is a Linux daemon 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 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
turbostat can display the frequency, power consumption, idle status and other statistics of the modern Intel and AMD CPUs.
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-guiAUR 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 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.
gnome-shell-extension-cpupower-gitAUR is a GNOME shell extension that can alter minimum/maximum CPU frequencies and enable/disable frequency boosting.
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.
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.
power-profiles-daemon service. Note that when powerprofilesctl is launched, it also attempts to start the service (see the unit status of
power-profiles-daemonservice by masking it (see also , ).
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.
- The native CPU module is loaded automatically.
intel_pstateCPU 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. The
intel_pstatemay ignore the BIOS P-State settings.
intel_pstatemay run in "passive mode" via the
intel_cpufreqdriver for older CPUs. If you encounter a problem while using this driver, add
intel_pstate=disableto your kernel line in order to revert to using the
amd_pstateCPU 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=activeas 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 disablederror. Change Enable 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:
|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.|
|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 a SpeedStep driver 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
- To adjust for only a single CPU core, append
- The governor, maximum and minimum frequencies can be set in
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. 
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:
# echo 0 > /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 has two operation modes: CPPC Autonomous(active) mode and CPPC non-autonomous(passive) mode. active mode and passive mode can be chosen by kernel parameter
amd_pstate=passive. A new "guided" mode is mentioned in the kernel documentation but will only be available in 6.4 (not yet released).
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 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.
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:
amd_pstatein active mode, which provide pseudo-governors in the form of
performance. See #CPU self-scaling below.
|performance||Run the CPU at the maximum frequency, obtained from |
|powersave||Run the CPU at the minimum frequency, obtained from |
|userspace||Run the CPU at user specified frequencies, configurable via |
|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 , .|
Depending on the scaling driver, one of these governors will be loaded by default:
schedutilsince Linux 4.9.5
- the internal
powersavegovernor for Intel CPUs using the
intel_pstatedriver (see the note above, it is equivalent to
To activate a particular governor, run:
# cpupower frequency-set -g governor
- To adjust for only a single CPU core, append
-c core_numberto 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
$ watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq
Tuning the ondemand governor
See the kernel documentation for details.
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
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
To have the desired scaling enabled at boot, kernel module options and systemd-tmpfiles are regular methods.
For example, changing the up_threshold to 10:
w- /sys/devices/system/cpu/cpufreq/ondemand/up_threshold - - - - 10
However, as noted in systemd-tmpfiles, in some cases, race conditions may exist and one can use udev to avoid them. For example:
$ udevadm info -a /sys/devices/cpu
... KERNEL=="cpu" SUBSYSTEM=="event_source" ...
KERNEL=="cpu", SUBSYSTEM=="event_source", ACTION=="add", RUN+="/bin/sh -c 'echo performance | tee /sys/devices/system/cpu/cpufreq/policy*/scaling_governor'"
$ udevadm test /sys/devices/cpu
... Reading rules file: /usr/lib/udev/rules.d/99-systemd.rules Reading rules file: /etc/udev/rules.d/cpu.rules ...
To have the rule already applied in the initramfs, add the file to your
mkinitcpio.conf, like in a different example in udev#Debug output.
CPU self-governing: CPPC and HWP
ACPI 5.0 introduces the concept of collaborative processor performance control (CPPC) in which the CPU can decide its own frequency based on workload and a performance/power hint from the system. The fully-autonomous mode is activated when:
amd-pstateis set to "active" – requires manual configuration
intel-pstateis 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,
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
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
performance, but the driver itself does the governing in a way similar to
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*/power/energy_performance_preference describe the current preference and
/sys/devices/system/cpu/cpu*/power/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 the CPPC "performance number" (which maps to frequencies on a model-specific basis) system.
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 are:
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
# x86_energy_perf_policy --epb epb
Setting via cpupower
# cpupower set -b epb_value
Other x86 Energy Flags
Enable Hardware P-States with x86_energy_perf_policy:
# x86_energy_perf_policy -H 1 # x86_energy_perf_policy -U 1
Set "default" policy:
The changes are temporary. See x86_energy_perf_policy(8) for more info.
CPU idle driver
intel_idle CPU idle driver is used automatically for modern Intel CPUs instead of the
acpi_idle driver. This driver is currently automatically used for Sandy Bridge and newer CPUs. The
intel_idle may ignore the BIOS C-State settings. If you encounter a problem while using this driver, add
intel_idle.max_cstate=0 to your kernel line.
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
conservative when the AC adapter is disconnected and change it back if reconnected:
[...] 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 ;; [...]
- 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
on-demandgovernor 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
on-demandgovernor (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 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
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.
A special parameter has to be passed to the processor module.
For trying this temporarily, change the value in
For setting it permanently, Kernel modules#Setting module options describes alternatives. For example, you can add
processor.ignore_ppc=1 to your kernel boot line, or create
# If the frequency of your machine gets wrongly limited by BIOS, this should help options processor ignore_ppc=1