world leader in high performance signal processing
Trace: » cpufreq

Enabling CPU frequency and voltage scaling

During kernel configuration enable 'CPU Frequency scaling' and select the governors you are going to use.

[*] CPU Frequency scaling                                  
[ ]   Enable CPUfreq debugging                             
<*>   CPU frequency translation statistics                 
[ ]     CPU frequency translation statistics details       
      Default CPUFreq governor (ondemand)  --->            
---   'performance' governor                               
<*>   'powersave' governor                                 
<*>   'userspace' governor for userspace frequency scaling 
---   'ondemand' cpufreq policy governor                   
<*>   'conservative' cpufreq governor 

CPU frequency and voltage scaling code in the Linux(TM) kernel

		         L i n u x    C P U F r e q


		    Dominik Brodowski  <linux@brodo.de>


   Clock scaling allows you to change the clock speed of the CPUs on the
    fly. This is a nice method to save battery power, because the lower
            the clock speed, the less power the CPU consumes.

Taken from linux-2.6.x/Documentation/cpu-freq - for more information see there:

"Policy" / "Governor" ?

Some CPU frequency scaling-capable processor switch between various frequencies and operating voltages “on the fly” without any kernel or user involvement. This guarantees very fast switching to a frequency which is high enough to serve the user's needs, but low enough to save power.

Policy

On these systems, all you can do is select the lower and upper frequency limit as well as whether you want more aggressive power-saving or more instantly available processing power.

Governor

On all other cpufreq implementations, these boundaries still need to be set. Then, a “governor” must be selected. Such a “governor” decides what speed the processor shall run within the boundaries. One such “governor” is the “userspace” governor. This one allows the user - or a yet-to-implement userspace program - to decide what specific speed the processor shall run at.

How to change the CPU cpufreq policy and/or speed

3.1 Preferred Interface: sysfs

The preferred interface is located in the sysfs filesystem. If you mounted it at /sys, the cpufreq interface is located in a subdirectory “cpufreq” within the cpu-device directory (e.g. /sys/devices/system/cpu/cpu0/cpufreq/ for the first CPU).

cpuinfo_min_freq :		this file shows the minimum operating
				frequency the processor can run at(in kHz) 
cpuinfo_max_freq :		this file shows the maximum operating
				frequency the processor can run at(in kHz) 
scaling_driver :		this file shows what cpufreq driver is
				used to set the frequency on this CPU

scaling_available_governors :	this file shows the CPUfreq governors
				available in this kernel. You can see the
				currently activated governor in

scaling_governor,		and by "echoing" the name of another
				governor you can change it. Please note
				that some governors won't load - they only
				work on some specific architectures or
				processors.
scaling_min_freq and
scaling_max_freq		show the current "policy limits" (in
				kHz). By echoing new values into these
				files, you can change these limits.
				NOTE: when setting a policy you need to
				first set scaling_max_freq, then
				scaling_min_freq.

If you have selected the “userspace” governor which allows you to set the CPU operating frequency to a specific value, you can read out the current frequency in

scaling_setspeed.		By "echoing" a new frequency into this
				you can change the speed of the CPU,
				but only within the limits of
				scaling_min_freq and scaling_max_freq.
				

The Governor Interface in the CPUfreq Core

What Is A CPUFreq Governor?

Most cpufreq drivers (in fact, all except one, longrun) or even most cpu frequency scaling algorithms only offer the CPU to be set to one frequency. In order to offer dynamic frequency scaling, the cpufreq core must be able to tell these drivers of a “target frequency”. So these specific drivers will be transformed to offer a ”→target” call instead of the existing ”→setpolicy” call. For “longrun”, all stays the same, though.

How to decide what frequency within the CPUfreq policy should be used? That's done using “cpufreq governors”. Two are already in this patch -- they're the already existing “powersave” and “performance” which set the frequency statically to the lowest or highest frequency, respectively. At least two more such governors will be ready for addition in the near future, but likely many more as there are various different theories and models about dynamic frequency scaling around. Using such a generic interface as cpufreq offers to scaling governors, these can be tested extensively, and the best one can be selected for each specific use.

Basically, it's the following flow graph:

CPU can be set to switch independently	 |	   CPU can only be set
      within specific "limits"		 |       to specific frequencies

                                 "CPUfreq policy"
		consists of frequency limits (policy->{min,max})
  		     and CPUfreq governor to be used
			 /		      \
			/		       \
		       /		       the cpufreq governor decides
		      /			       (dynamically or statically)
		     /			       what target_freq to set within
		    /			       the limits of policy->{min,max}
		   /			            \
		  /				     \
	Using the ->setpolicy call,		 Using the ->target call,
	    the limits and the			  the frequency closest
	     "policy" is set.			  to target_freq is set.
						  It is assured that it
						  is within policy->{min,max}

Governors In the Linux Kernel

Performance

The CPUfreq governor “performance” sets the CPU statically to the highest frequency within the borders of scaling_min_freq and scaling_max_freq.

Powersave

The CPUfreq governor “powersave” sets the CPU statically to the lowest frequency within the borders of scaling_min_freq and scaling_max_freq.

Userspace

The CPUfreq governor “userspace” allows the user, or any userspace program running with UID “root”, to set the CPU to a specific frequency by making a sysfs file “scaling_setspeed” available in the CPU-device directory.

Ondemand

The CPUfreq governor “ondemand” sets the CPU depending on the current usage. To do this the CPU must have the capability to switch the frequency very quickly. There are a number of sysfs file accessible parameters:

sampling_rate: measured in uS (10^-6 seconds), this is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more.

show_sampling_rate_(min|max): the minimum and maximum sampling rates available that you may set 'sampling_rate' to.

up_threshold: defines what the average CPU usaged between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased.

sampling_down_factor: this parameter controls the rate that the CPU makes a decision on when to decrease the frequency. When set to its default value of '5' it means that at 1/5 the sampling_rate the kernel makes a decision to lower the frequency. Five “lower rate” decisions have to be made in a row before the CPU frequency is actually lower. If set to '1' then the frequency decreases as quickly as it increases, if set to '2' it decreases at half the rate of the increase.

ignore_nice_load: this parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency.

Conservative

The CPUfreq governor “conservative”, much like the “ondemand” governor, sets the CPU depending on the current usage. It differs in behaviour in that it gracefully increases and decreases the CPU speed rather than jumping to max speed the moment there is any load on the CPU. This behaviour more suitable in a battery powered environment. The governor is tweaked in the same manner as the “ondemand” governor through sysfs with the addition of:

freq_step: this describes what percentage steps the cpu freq should be increased and decreased smoothly by. By default the cpu frequency will increase in 5% chunks of your maximum cpu frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the “ondemand” governor.

down_threshold: same as the 'up_threshold' found for the “ondemand” governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased.

The Governor Interface in the CPUfreq Core

A new governor must register itself with the CPUfreq core using “cpufreq_register_governor”. The struct cpufreq_governor, which has to be passed to that function, must contain the following values:

governor->name -	    A unique name for this governor
governor->governor -	    The governor callback function
governor->owner	-	    .THIS_MODULE for the governor module (if 
			    appropriate)

The governor→governor callback is called with the current (or to-be-set) cpufreq_policy struct for that CPU, and an unsigned int event. The following events are currently defined:

CPUFREQ_GOV_START:   This governor shall start its duty for the CPU
		     policy->cpu
CPUFREQ_GOV_STOP:    This governor shall end its duty for the CPU
		     policy->cpu
CPUFREQ_GOV_LIMITS:  The limits for CPU policy->cpu have changed to
		     policy->min and policy->max.

If you need other “events” externally of your driver, _only_ use the cpufreq_governor_l(unsigned int cpu, unsigned int event) call to the CPUfreq core to ensure proper locking.

The CPUfreq governor may call the CPU processor driver using one of these two functions:

int cpufreq_driver_target(struct cpufreq_policy *policy,
                                 unsigned int target_freq,
                                 unsigned int relation);
 
int __cpufreq_driver_target(struct cpufreq_policy *policy,
                                   unsigned int target_freq,
                                   unsigned int relation);

target_freq must be within policy→min and policy→max, of course. What's the difference between these two functions? When your governor still is in a direct code path of a call to governor→governor, the per-CPU cpufreq lock is still held in the cpufreq core, and there's no need to lock it again (in fact, this would cause a deadlock). So use __cpufreq_driver_target only in these cases. In all other cases (for example, when there's a “daemonized” function that wakes up every second), use cpufreq_driver_target to lock the cpufreq per-CPU lock before the command is passed to the cpufreq processor driver.

Testing via sysfs

root:/sys/devices/system/cpu/cpu0/cpufreq> ls -l
-r--r--r--    1 root     root         4096 Jan  1 01:07 affected_cpus
-r--------    1 root     root         4096 Jan  1 01:07 cpuinfo_cur_freq
-r--r--r--    1 root     root         4096 Jan  1 01:07 cpuinfo_max_freq
-r--r--r--    1 root     root         4096 Jan  1 01:07 cpuinfo_min_freq
drwxr-xr-x    2 root     root            0 Jan  1 01:07 ondemand
-r--r--r--    1 root     root         4096 Jan  1 01:07 scaling_available_frequencies
-r--r--r--    1 root     root         4096 Jan  1 01:07 scaling_available_governors
-r--r--r--    1 root     root         4096 Jan  1 01:07 scaling_cur_freq
-r--r--r--    1 root     root         4096 Jan  1 01:07 scaling_driver
-rw-r--r--    1 root     root         4096 Jan  1 01:07 scaling_governor
-rw-r--r--    1 root     root         4096 Jan  1 01:07 scaling_max_freq
-rw-r--r--    1 root     root         4096 Jan  1 01:07 scaling_min_freq
drwxr-xr-x    2 root     root            0 Jan  1 01:07 stats

root:/sys/devices/system/cpu/cpu0/cpufreq> cat scaling_available_frequencies
500000 250000

root:/sys/devices/system/cpu/cpu0/cpufreq> cd stats/
root:/sys/devices/system/cpu/cpu0/cpufreq/stats> cat *
500000 33881
250000 306842
5583
   From  :    To
         : 500000 250000
500000:         0      2792
250000:      2791         0

root:/sys/devices/system/cpu/cpu0/cpufreq> while [ 1 ];md5sum /bin/busybox;sleep 1;done
4b6335cb9fe7bd29f7ad62d7abae3a56  /bin/busybox
4b6335cb9fe7bd29f7ad62d7abae3a56  /bin/busybox
4b6335cb9fe7bd29f7ad62d7abae3a56  /bin/busybox
4b6335cb9fe7bd29f7ad62d7abae3a56  /bin/busybox
4b6335cb9fe7bd29f7ad62d7abae3a56  /bin/busybox


root:/sys/devices/system/cpu/cpu0/cpufreq> cat stats/*
500000 33936
250000 323782
5593
   From  :    To
         : 500000 250000
500000:         0      2797
250000:      2796         0
root:/sys/devices/system/cpu/cpu0/cpufreq> cat scaling_governor
ondemand
root:/sys/devices/system/cpu/cpu0/cpufreq>

Testing via cpufreq-utils

In order to modify frequency settings with cpufreq-utils, you need to have the userspace governor enabled.

root:/> cpufreq-info
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: bfin cpufreq
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 250 MHz - 500 MHz
  available frequency steps: 500 MHz, 250 MHz
  available cpufreq governors: userspace, performance
  current policy: frequency should be within 250 MHz and 500 MHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency is 500 MHz (asserted by call to hardware).
  cpufreq stats: 500 MHz:100.00%, 250 MHz:0.00%

root:/> cpufreq-set -f 250000

root:/> cpufreq-info
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: bfin cpufreq
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 250 MHz - 500 MHz
  available frequency steps: 500 MHz, 250 MHz
  available cpufreq governors: userspace, performance
  current policy: frequency should be within 250 MHz and 500 MHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency is 250 MHz (asserted by call to hardware).
  cpufreq stats: 500 MHz:92.73%, 250 MHz:7.27%  (1)

root:/> cat /proc/cpuinfo
processor       : 0
vendor_id       : Analog Devices
cpu family      : 0x27c8
model name      : ADSP-BF537 250(MHz CCLK) 100(MHz SCLK) (mpu off)
stepping        : 3
cpu MHz         : 250.000/100.000
bogomips        : 498.68
Calibration     : 249344000 loops
cache size      : 16 KB(L1 icache) 32 KB(L1 dcache-wt) 0 KB(L2 cache)
dbank-A/B       : cache/cache
icache setup    : 4 Sub-banks/4 Ways, 32 Lines/Way
dcache setup    : 2 Super-banks/4 Sub-banks/2 Ways, 64 Lines/Way
board name      : ADDS-BF537-STAMP
board memory    : 65536 kB (0x00000000 -> 0x04000000)
kernel memory   : 64504 kB (0x00001000 -> 0x03eff000)

root:/> cpufreq-set -f 500000

root:/> cat /proc/cpuinfo
processor       : 0
vendor_id       : Analog Devices
cpu family      : 0x27c8
model name      : ADSP-BF537 500(MHz CCLK) 100(MHz SCLK) (mpu off)
stepping        : 3
cpu MHz         : 500.000/100.000
bogomips        : 997.37
Calibration     : 498688000 loops
cache size      : 16 KB(L1 icache) 32 KB(L1 dcache-wt) 0 KB(L2 cache)
dbank-A/B       : cache/cache
icache setup    : 4 Sub-banks/4 Ways, 32 Lines/Way
dcache setup    : 2 Super-banks/4 Sub-banks/2 Ways, 64 Lines/Way
board name      : ADDS-BF537-STAMP
board memory    : 65536 kB (0x00000000 -> 0x04000000)
kernel memory   : 64504 kB (0x00001000 -> 0x03eff000)
root:/>