Difference between revisions of "CPU frequency scaling"

From ArchWiki
Jump to navigation Jump to search
Line 12: Line 12:
{{Article summary wiki|Laptop Mode Tools|Laptop_Mode_Tools}}
{{Article summary wiki|Laptop Mode Tools|Laptop_Mode_Tools}}
{{Article summary wiki|pm-utils}}
{{Article summary wiki|pm-utils}}
{{Article summary wiki|powernowd}}
{{Article summary end}}
{{Article summary end}}

Revision as of 04:17, 2 April 2011

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Template:Moveto Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary end

cpufreq refers to the kernel infrastructure that implements CPU frequency scaling, a technology used primarily by notebooks that enables the operating system to scale the CPU speed up or down, depending on the current system load.

In order to use scaling, the needed modules have to be loaded and then a governor has to be set. cpufrequtils, acpid and laptop-mode-tools each offer different ways of managing cpufreq. You can also use the simple CPU frequency applets included with some desktop environments instead.


Template:Package Official is a set of userspace utilities designed to assist with CPU frequency scaling. The package isn't required to use scaling, but is highly recommended because it provides useful command-line utilities and a daemon script to set the governor at boot.

Template:Package Official provides similar information to the cpufreq-info utility in this package, but not at the same level of detail.

The Template:Package Official package is available in the [extra] repository:

# pacman -S cpufrequtils


Configuring CPU scaling is a 3-part process:

  1. Load appropriate CPU frequency driver
  2. Load desired scaling governor(s)
  3. Select a method to manage switching the governor: manually (via /sys or cpufreq-set), the cpufrequtils #Daemon, laptop-mode-tools, acpid or using an applet/desktop environment. Different methods can be combined if desired.
  4. Optionally, the scaling governor can be tuned with cpufrequtils and/or the /sys interface.

CPU frequency driver

In order for frequency scaling to work properly, the operating system must first know the limits of the CPU(s). To accomplish this, a kernel module is loaded that can read and manage the specifications of the CPU(s).

Most modern notebooks and desktops can simply use the acpi-cpufreq driver. However, other options include the p4-clockmod, powernow-k8, and speedstep-centrino drivers. To see a full list of available drivers, run the following:

$ ls /lib/modules/2.6.??-ARCH/kernel/drivers/cpufreq
Tip: For an AMD "K10" CPU like Phenom X4, use the powernow-k8 driver.

To load the CPU frequency driver manually:


# modprobe acpi_cpufreq

For older Intel CPUs, the command above may return with:

FATAL: Error inserting acpi_cpufreq ([...]/acpi-cpufreq.ko): No such device

In this case, replace the kernel module acpi_cpufreq with speedstep-centrino, p4-clockmod or speedstep-ich.

Tip: Notice that the speedstep-centrino module is deprecated, and the p4-clockmod supports only performance and powersave governors (due to long transition latency of the module itself)

There is a kernel with the speedstep-centrino module patched on the AUR, it is the kernel26-pentium-m package which is located here: http://aur.archlinux.org/packages.php?ID=33104


# modprobe powernow-k8

Loading at boot

To load the driver automatically at startup, add the appropriate driver to the MODULES array within Template:Filename. For example:

MODULES=( acpi-cpufreq vboxdrv fuse fglrx iwl3945 ... )

Once the appropriate cpufreq driver is loaded, detailed information about the CPU(s) can be displayed by running:

$ cpufreq-info

The output should appear similar to the following:


To simply see which governors are available:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

Monitoring the CPU speed in real-time can be achieved by running:

watch grep \"cpu MHz\" /proc/cpuinfo

Privilege Granting Under Gnome

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 Template:Filename and populate it with the following:


Where the word USER is replaced with the username of interest.

The Template:Package AUR package in the AUR contains a similar .pkla file for authorizing all users of the power group to change the governor.

Laptop Mode Tools

If you are already using or plan to use Laptop Mode Tools for other power saving solutions, you may want to let it manage also CPU frequency scaling. In that case you just have to insert the acpi-cpufreq module to the MODULES array in Template:Filename:


And then go through the Template:Filename to define governors, frequencies and policies.

If you use laptop-mode-tools to manage cpufrequtils, then you won't need to load other modules and daemons or to set up scaling governors and interaction with ACPI events. Please refer to Laptop Mode Tools to know how to install and configure laptop-mode-tools.

Scaling governors

Governors can be thought of as pre-configured power schemes for the CPU. These governors must be loaded as kernel modules in order to be seen by such programs as kpowersave and gnome-power-manager. One may load as many governors as desired (only one will be active at any given time).

Available governors:

Template:Codeline (default)
The performance governor is built into the kernel and runs the CPU(s) at maximum clock speed
Template:Codeline (recommended)
Dynamically increases/decreases the CPU(s) clock speed based on system load
Similar to Template:Codeline, but more conservative (clock speed changes are more graceful)
Runs the CPU at minimum speed
Manually configured clock speeds by user

Load the desired governor(s) with Template:Codeline. For example:

# modprobe cpufreq_ondemand
# modprobe cpufreq_userspace

Or, add the desired governor(s) to the MODULES array in Template:Filename and reboot.

MODULES=(acpi-cpufreq cpufreq_ondemand cpufreq_powersave)

Manually set the governor by running the Template:Codeline command (as root). However, this setting will not be saved after a reboot/shutdown. For example:

# cpufreq-set -g ondemand

Note that the previous command only sets the governor for the first processor. If you have a multicore or multiprocessor system, use the -c flag to set the governor for a specific core. For example, to set the governor for the fourth core (core numbers start from zero):

# cpufreq-set -c 3 -g ondemand

Run Template:Codeline or Template:Codeline for more information.

For those who would like a GUI for setting governors or frequency there is trayfreq, a GTK+ application that sits in the system tray.

Changing the Template:Codeline governor's threshold

To change when the Template:Codeline governor switches to a higher multiplier, one can manipulate Template:Filename. Determine the current setting by issuing the following command as root:

# cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

The value returned should be 95, the default setting as of kernel version 2.6.37. This means that the Template:Codeline governor currently increases the clock rate if a core reaches 95% utilization. The can be changed, for example:

echo "15" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
Note: The minimum value one can enter must be above the one in down_threshold; entering a value under that results in the error, "bash: echo: write error: Invalid argument"
Note: Appending the echo line to the Template:Filename will allow it to "survive" a reboot. However, in order for this to work, the governor must be set to Template:Codeline prior to Template:Filename's processing since Template:Filename does not exist unless the Template:Codeline governor is running. Starting the cpufreq daemon in the background (i.e. with an '@' in Template:Filename) will likely cause Template:Filename to be processed before the cpufreq daemon has a chance to change the governor.

If you simply must background the starting of cpufreq (i.e. for a negligible start up time reduction), the following workaround may be added to your Template:Filename:

(sleep 30 && sh -c "echo -n 75 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold")& 

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. Events are defined in Template:Filename. If the Template:Package Official package is installed, the file should already exist and be executable. For example, to change the scaling governor from Template:Codeline to Template:Codeline when the AC adapter is disconnected and change it back if reconnected:



cpufrequtils also includes a daemon which allows users to set the desired scaling governor and min/max clock speeds for all processor cores at boot-time, without the need for additional tools such as kpowersave.

Before starting the daemon, edit Template:Filename as root, selecting the desired governor and setting the min/max speed for your CPU(s), for example:


Note: The exact min/max values of the CPU(s) can be determined by running Template:Codeline after loading the CPU driver (e.g. Template:Codeline). However, these values are optional. Users may omit them entirely by deleting or commenting out the min/max_freq lines; scaling will work automatically.

With the appropriate configuration, start the daemon with the following command:

# /etc/rc.d/cpufreq start

To start the daemon automatically at startup, add Template:Codeline to the DAEMONS array in Template:Filename, for example:

DAEMONS=(syslog-ng networkmanager @alsa @crond @cups @cpufreq)


  • 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 Template:Codeline governor cannot change the frequency quickly enough when a lot of packages suddenly arrive at the monitored network interface that cannot be handled by the current processor speed.
  • Some CPUs may suffer from poor performance with the default settings of the Template:Codeline 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 #Changing the ondemand governor's threshold.
  • Sometimes the deamon may not throttle to the maximum frequence but one step below. This can be solved by setting max_freq value slightly higher than the real maximum. For example, if frequence range of the CPU is from 2.00GHz to 3.00GHz, setting max_freq to 3.01GHz can be a good idea.
  • Some cpu/bios configurations may have difficulties to scale to the maximum frequencies or scale to highter frequencies at all. Sadly there is only a workaround right now. Add "processor.ignore_ppc=1" to your kernel boot line and/or edit the value in /sys/module/processor/parameters/ignore_ppc from 0 to 1.