CPU frequency scaling

From ArchWiki
Revision as of 10:07, 23 June 2012 by Kynikos (Talk | contribs) (Scaling governors: it's true that we're currently at linux 3.4, but for example we're still supporting linux-lts at 3.0; this format should be more flexible)

Jump to: navigation, search

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

cpufreq refers to the kernel infrastructure that implements CPU frequency scaling. This technology enables the operating system to scale the CPU speed 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.

Since kernel 3.4 the necessary modules are loaded automatically and the recommended ondemand governor is enabled by default. However, userspace applications like #cpufrequtils, acpid, laptop-mode-tools, or GUI tools provided for your desktop environment, may still be used for advanced configuration.

cpufrequtils

cpufrequtils 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 daemon script to set the governor at boot (see #Daemon below).

The cpufrequtils package is available in the official repositories.

cpupower

cpupower is based on cpufrequtils and it extends some features. The configuration is pretty much the same as with cpufrequtils. More information on: http://lwn.net/Articles/433002/

Tip: Make sure you edit /etc/conf.d/cpupower and set the governor/frequencies you desire before starting cpupower daemon

Configuration

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 and tuning governor(s):

CPU frequency driver

Note: The CPU frequency driver for your CPU is automatically loaded since kernel 3.4, therefore loading it manually - as described in this section - should not be necessary anymore.

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). Note that these modules may need related features enabled in BIOS which may be labeled as: Speedstep, Cool and Quiet, PowerNow!, or ACPI.

If you have a 64-bit processor, you will very likely want either acpi-cpufreq for Intel processors or powernow-k8 for AMD K8/K10 processors (Athlon 64, Opteron, and Phenom). These modules are built for both 32 and 64-bit kernels so even if you run a 32-bit kernel on your 64-bit hardware they are probably still the ones you want.

To see a full list of available drivers, run the following:

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

The following table is a partial list of available frequency drivers (Adapted from kernel source file <kernel source>/arch/x86/kernel/cpu/cpufreq/Kconfig).

Module Description
acpi-cpufreq CPUFreq driver which utilizes the ACPI Processor Performance States. This driver also supports Intel Enhanced Speedstep (previously supported by the deprecated speedstep-centrino module).
speedstep-ich CPUFreq driver for certain mobile Intel Pentium III (Coppermine), all mobile Intel Pentium III-M (Tualatin) and all mobile Intel Pentium 4 P4-M on systems which have an Intel ICH2, ICH3 or ICH4 southbridge.
speedstep-smi CPUFreq driver for certain mobile Intel Pentium III (Coppermine), all mobile Intel Pentium III-M (Tualatin) on systems which have an Intel 440BX/ZX/MX southbridge.
powernow-k8 CPUFreq driver for K8/K10 Athlon64/Opteron/Phenom processors.
powernow-k7 CPUFreq driver for mobile AMD K7 mobile processors.
cpufreq-nforce2 CPUFreq driver for FSB changing on nVidia nForce2 platforms. (AMD K7, Socket A)
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. When enabled it will lower CPU temperature by skipping clocks.
You probably want to use a Speedstep driver instead.


To load the CPU frequency driver manually:

# modprobe acpi-cpufreq

Note that if you attempt to load the wrong module you will get an error such as

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

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

$ cpufreq-info
 analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: ondemand, performance
  current policy: frequency should be within 1000 MHz and 2.00 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.00 GHz.
 analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: ondemand, performance
  current policy: frequency should be within 1000 MHz and 2.00 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.00 GHz.

To load the driver automatically at startup, add the appropriate driver to the MODULES array in /etc/rc.conf. For example:

MODULES=(acpi-cpufreq)

Scaling governors

Governors can be thought of as pre-configured power schemes for the CPU. Some of the governors must be loaded as kernel modules in order to be seen by user space programs. One may load as many governors as desired (only one will be active on a CPU at any given time).

Available governors:

cpufreq_ondemand (default and recommended)
Dynamically switches between the CPU(s) available clock speeds based on system load
cpufreq_performance
The performance governor runs the CPU(s) at maximum clock speed
cpufreq_conservative
Similar to ondemand, but the CPU(s) clock speed switches gradually through all its available frequencies based on system load
cpufreq_powersave
Runs the CPU(s) at minimum speed
cpufreq_userspace
Manually configured clock speeds by user

For Desktops and most systems, the ondemand governor can provide the best compromise between heat emission, power consumption, performance, and manageability. Since it is the default and built into the kernel, loading the CPU frequency driver should be sufficient to activate it. For Laptops or other mobile systems, the conservative governor can possibly provide significant savings in power consumption.

The governors ondemand and performance are built into the kernel and do not need to be loaded as modules. If you want to use one of the other governors, you have to load them with modprobe. For example:

# modprobe cpufreq_powersave
# modprobe cpufreq_userspace

Or, add the desired governor(s) to the MODULES array in /etc/rc.conf and reboot.

MODULES=(... cpufreq_powersave cpufreq_userspace ...)

To see which governors have been loaded:

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

To see which frequencies are supported:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

Manually set the governor by running the cpufreq-set command (as root). For example:

# cpufreq-set -c 0 -g ondemand

Note that the previous command only sets the governor for the first processor! Multicore or multiprocessor systems require the -c flag to set the governor for a specific core and to repeat for each remaining. Numbering starts from 0 not 1!

For a quad core chip:

# for i in 0 1 2 3; do cpufreq-set -c $i -g ondemand; done

For a dual core chip:

# for i in 0 1; do cpufreq-set -c $i -g ondemand; done

Or use -r flag to set governor for all related cores

# cpufreq-set -r -g ondemand
Note: These settings will not be preserved after a reboot/shutdown. See the #Daemon section below for configuring cpufreq governors at boot.

Additional options such as upper and lower frequency bounds used by the governor can optionally be set by using the -u and -d options. A processors valid frequencies can be seen by calling cpufreq-info. For example, to set the second core's upper frequency bound as 2.00GHz and its lower bound as 1.00 GHz:

# cpufreq-set -c 1 -g ondemand -u 2.00Ghz -d 1.00Ghz

To manually set a processor to a specific frequency the userspace governor is used. For example, to set core 0 to 2.50Ghz and core 1 to 800Mhz:

# cpufreq-set -c 0 -f 2.50Ghz
# cpufreq-set -c 1 -f 800Mhz

Run cpufreq-set --help or man cpufreq-set 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.

The monitoring of CPU clock in real-time is accomplished by running:

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

or (as root, so not nearly as useful)

# watch -n.5 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

or

# watch -n.5 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

Improving on-demand performance

With the out-of-the-box configuration, the ondemand governor will result in a slight but measurable and noticeable loss of performance. It will not clock up the CPU when it is at lower than 95% usage, and will sample the usage at the fastest possible frequency when at full clock speeds in order to clock back down as soon as possible.

Tuning the governor for your needs can reduce the performance loss to the point where it is negligible/non-existent if you are willing to lose a lot of the power savings. If you just want to save power while idle, lowering the up_threshold to 11% and raising the sample_down_factor by an order of magnitude can accomplish this.

Tunables are available in /sys/devices/system/cpu/cpufreq/ondemand/ once the governor is loaded and selected and can be preserved at reboot using /etc/rc.local.

Starting the cpufreq daemon in the background (i.e. with an @ in /etc/rc.conf) will likely cause /etc/rc.local to be processed before the cpufreq daemon has a chance to change the governor. Make sure that the cpufreq daemon script will have finished running before the tunables are set. Example:

/etc/rc.local
(sleep 10 && echo -n 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold) &
Changing the on-demand governor's threshold

To change when the ondemand governor switches to a higher multiplier, one can manipulate /sys/devices/system/cpu/cpufreq/ondemand/up_threshold. 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 3.0. This means that the ondemand governor currently increases the clock rate if a core reaches 95% utilization. This can be changed, for example:

# echo -n 15 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
On-demand governor sampling_down_factor

sampling_down_factor is another global ondemand global tunable.

Having sampling_down_factor set to 1 makes no changes from existing behavior, but having sampling_down_factor set to a value greater than 1 (e.g. 100) causes it to act as a multiplier for the scheduling interval for re-evaluating load when the CPU is at its highest clock frequency due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.

Read the value (default: 1):

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

Set the value:

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

Tuning conservative governor

While the conservative governor switches smoothly and utilizes all of the available frequencies, users may want to tune it further. Out-of-the-box it will clock the CPU up when load reaches 75% and clock down when load drops to 20%. As with the on-demand governor, decreasing the up_threshold may improve performance and responsiveness.

Tunables are available in /sys/devices/system/cpu/cpufreq/conservative/. Refer to the #Improving ondemand performance section for important advice regarding making this changes permanent, and potential daemon loading issues.

Changing the conservative governor's thresholds

Determine the current up_threshold setting by issuing the following command as root:

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

The value returned should be 75, the default setting as of kernel version 3.0. This means that the conservative governor currently increases the clock rate to the next highest speed if a core reaches 75% utilization. The can be changed, for example:

# echo -n 40 > /sys/devices/system/cpu/cpufreq/conservative/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"

Similarly the down_threshold value can be read and modified via /sys/devices/system/cpu/cpufreq/conservative/down_threshold. The default value should be 20 as of kernel version 3.0. This means that the conservative governor decreases the clock rate to the next lowest speed if a core falls to 20% utilization, which is a sensible default.

While the down sampling rate can also be adjusted for the conservative governor, increasing it may only help with occasional low usage CPU spikes during high usage applications, as the down_threshold is a much more direct control for down scaling which does not exist on the ondemand governor.

Be aware that setting down_threshold too close to up_threshold may result in constant CPU switching, which might be something desirable for certain users and not for others. Setting down_threshold or up_threshold too low may result in the CPU being clocked higher than it needs sacrificing power saving for performance, and setting up_threshold too high may result in decreased performance, but reduced power consumption. Experiment to find the optimal values for your system and your needs.

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
 ;;

[...]

Daemon

cpufrequtils includes a daemon which allows users to set the desired scaling governor and min/max clock speeds for all processor cores at boot-time.

Before starting the daemon, edit /etc/conf.d/cpufreq as root, selecting the desired governor and setting the min/max speed for your CPU(s), for example:

/etc/conf.d/cpufreq
#configuration for cpufreq control

# valid governors:
#  ondemand, performance, powersave,
#  conservative, userspace
governor="ondemand"

# valid suffixes: Hz, kHz (default), MHz, GHz, THz
min_freq="1GHz"
max_freq="2GHz"
Note: The exact min/max values of the CPU(s) can be determined by running cpufreq-info after loading the CPU driver (e.g. modprobe acpi-cpufreq). 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:

# rc.d start cpufreq

To start the daemon automatically at startup, add cpufreq to the DAEMONS array in /etc/rc.conf, for example:

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

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 /var/lib/polkit-1/localauthority/50-local.d/org.gnome.cpufreqselector.pkla and populate it with the following:

[org.gnome.cpufreqselector]
Identity=unix-user:USER
Action=org.gnome.cpufreqselector
ResultAny=no
ResultInactive=no
ResultActive=yes
0

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

The desktop-privilegesAUR 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, then you may want to let it also manage CPU frequency scaling. To do so, you just have to insert the appropriate frequency driver to the MODULES array in /etc/rc.conf (see #CPU frequency driver above) and then go through the /etc/laptop-mode/conf.d/cpufreq.conf file to define governors, frequencies and policies. You will not need to load other modules and daemons or to set up scaling governors and interaction with ACPI events. Please refer to Laptop Mode Tools for more details.

Troubleshooting

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:CPU frequency scaling#)
  • 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-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 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 #Changing 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 CPU/BIOS configurations may have difficulties to scale to the maximum frequencies or scale to higher 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.
    • It seems to be fixed at least since kernel 3.0, for Toshiba NB-100.
    • But this still seems not to be true for my fresh Thinkpad X60 Setup. The 32bit Intel Core Duo T2400 is still usually fixed at 1GHz with kernel 3.2.6-2 while only with the ignore_ppc option set (as described above) it's able to scale up to 1.83GHz like expected.
  • 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.