Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | CPU frequency and voltage scaling code in the Linux(TM) kernel |
| 2 | |
| 3 | |
| 4 | L i n u x C P U F r e q |
| 5 | |
| 6 | C P U F r e q G o v e r n o r s |
| 7 | |
| 8 | - information for users and developers - |
| 9 | |
| 10 | |
| 11 | Dominik Brodowski <linux@brodo.de> |
Nico Golde | 594dd2c | 2005-06-25 14:58:33 -0700 | [diff] [blame] | 12 | some additions and corrections by Nico Golde <nico@ngolde.de> |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 13 | |
| 14 | |
| 15 | |
| 16 | Clock scaling allows you to change the clock speed of the CPUs on the |
| 17 | fly. This is a nice method to save battery power, because the lower |
| 18 | the clock speed, the less power the CPU consumes. |
| 19 | |
| 20 | |
| 21 | Contents: |
| 22 | --------- |
| 23 | 1. What is a CPUFreq Governor? |
| 24 | |
| 25 | 2. Governors In the Linux Kernel |
| 26 | 2.1 Performance |
| 27 | 2.2 Powersave |
| 28 | 2.3 Userspace |
Nico Golde | 594dd2c | 2005-06-25 14:58:33 -0700 | [diff] [blame] | 29 | 2.4 Ondemand |
Alexander Clouter | 537208c | 2005-12-01 01:09:23 -0800 | [diff] [blame] | 30 | 2.5 Conservative |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 31 | |
| 32 | 3. The Governor Interface in the CPUfreq Core |
| 33 | |
| 34 | |
| 35 | |
| 36 | 1. What Is A CPUFreq Governor? |
| 37 | ============================== |
| 38 | |
| 39 | Most cpufreq drivers (in fact, all except one, longrun) or even most |
| 40 | cpu frequency scaling algorithms only offer the CPU to be set to one |
| 41 | frequency. In order to offer dynamic frequency scaling, the cpufreq |
| 42 | core must be able to tell these drivers of a "target frequency". So |
| 43 | these specific drivers will be transformed to offer a "->target" |
| 44 | call instead of the existing "->setpolicy" call. For "longrun", all |
| 45 | stays the same, though. |
| 46 | |
| 47 | How to decide what frequency within the CPUfreq policy should be used? |
| 48 | That's done using "cpufreq governors". Two are already in this patch |
| 49 | -- they're the already existing "powersave" and "performance" which |
| 50 | set the frequency statically to the lowest or highest frequency, |
| 51 | respectively. At least two more such governors will be ready for |
| 52 | addition in the near future, but likely many more as there are various |
| 53 | different theories and models about dynamic frequency scaling |
| 54 | around. Using such a generic interface as cpufreq offers to scaling |
| 55 | governors, these can be tested extensively, and the best one can be |
| 56 | selected for each specific use. |
| 57 | |
| 58 | Basically, it's the following flow graph: |
| 59 | |
Matt LaPlante | 2fe0ae7 | 2006-10-03 22:50:39 +0200 | [diff] [blame] | 60 | CPU can be set to switch independently | CPU can only be set |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 61 | within specific "limits" | to specific frequencies |
| 62 | |
| 63 | "CPUfreq policy" |
| 64 | consists of frequency limits (policy->{min,max}) |
| 65 | and CPUfreq governor to be used |
| 66 | / \ |
| 67 | / \ |
| 68 | / the cpufreq governor decides |
| 69 | / (dynamically or statically) |
| 70 | / what target_freq to set within |
| 71 | / the limits of policy->{min,max} |
| 72 | / \ |
| 73 | / \ |
| 74 | Using the ->setpolicy call, Using the ->target call, |
| 75 | the limits and the the frequency closest |
| 76 | "policy" is set. to target_freq is set. |
| 77 | It is assured that it |
| 78 | is within policy->{min,max} |
| 79 | |
| 80 | |
| 81 | 2. Governors In the Linux Kernel |
| 82 | ================================ |
| 83 | |
| 84 | 2.1 Performance |
| 85 | --------------- |
| 86 | |
| 87 | The CPUfreq governor "performance" sets the CPU statically to the |
| 88 | highest frequency within the borders of scaling_min_freq and |
| 89 | scaling_max_freq. |
| 90 | |
| 91 | |
Nico Golde | 594dd2c | 2005-06-25 14:58:33 -0700 | [diff] [blame] | 92 | 2.2 Powersave |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 93 | ------------- |
| 94 | |
| 95 | The CPUfreq governor "powersave" sets the CPU statically to the |
| 96 | lowest frequency within the borders of scaling_min_freq and |
| 97 | scaling_max_freq. |
| 98 | |
| 99 | |
Nico Golde | 594dd2c | 2005-06-25 14:58:33 -0700 | [diff] [blame] | 100 | 2.3 Userspace |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 101 | ------------- |
| 102 | |
| 103 | The CPUfreq governor "userspace" allows the user, or any userspace |
| 104 | program running with UID "root", to set the CPU to a specific frequency |
| 105 | by making a sysfs file "scaling_setspeed" available in the CPU-device |
| 106 | directory. |
| 107 | |
| 108 | |
Nico Golde | 594dd2c | 2005-06-25 14:58:33 -0700 | [diff] [blame] | 109 | 2.4 Ondemand |
| 110 | ------------ |
| 111 | |
Matt LaPlante | a2ffd27 | 2006-10-03 22:49:15 +0200 | [diff] [blame] | 112 | The CPUfreq governor "ondemand" sets the CPU depending on the |
Nico Golde | 594dd2c | 2005-06-25 14:58:33 -0700 | [diff] [blame] | 113 | current usage. To do this the CPU must have the capability to |
Alexander Clouter | 537208c | 2005-12-01 01:09:23 -0800 | [diff] [blame] | 114 | switch the frequency very quickly. There are a number of sysfs file |
| 115 | accessible parameters: |
| 116 | |
| 117 | sampling_rate: measured in uS (10^-6 seconds), this is how often you |
| 118 | want the kernel to look at the CPU usage and to make decisions on |
| 119 | what to do about the frequency. Typically this is set to values of |
| 120 | around '10000' or more. |
| 121 | |
| 122 | show_sampling_rate_(min|max): the minimum and maximum sampling rates |
| 123 | available that you may set 'sampling_rate' to. |
| 124 | |
| 125 | up_threshold: defines what the average CPU usaged between the samplings |
| 126 | of 'sampling_rate' needs to be for the kernel to make a decision on |
| 127 | whether it should increase the frequency. For example when it is set |
| 128 | to its default value of '80' it means that between the checking |
| 129 | intervals the CPU needs to be on average more than 80% in use to then |
| 130 | decide that the CPU frequency needs to be increased. |
| 131 | |
Matt LaPlante | 992caac | 2006-10-03 22:52:05 +0200 | [diff] [blame] | 132 | ignore_nice_load: this parameter takes a value of '0' or '1'. When |
| 133 | set to '0' (its default), all processes are counted towards the |
| 134 | 'cpu utilisation' value. When set to '1', the processes that are |
Alexander Clouter | 537208c | 2005-12-01 01:09:23 -0800 | [diff] [blame] | 135 | run with a 'nice' value will not count (and thus be ignored) in the |
Matt LaPlante | 992caac | 2006-10-03 22:52:05 +0200 | [diff] [blame] | 136 | overall usage calculation. This is useful if you are running a CPU |
Alexander Clouter | 537208c | 2005-12-01 01:09:23 -0800 | [diff] [blame] | 137 | intensive calculation on your laptop that you do not care how long it |
| 138 | takes to complete as you can 'nice' it and prevent it from taking part |
| 139 | in the deciding process of whether to increase your CPU frequency. |
Nico Golde | 594dd2c | 2005-06-25 14:58:33 -0700 | [diff] [blame] | 140 | |
| 141 | |
Alexander Clouter | 537208c | 2005-12-01 01:09:23 -0800 | [diff] [blame] | 142 | 2.5 Conservative |
| 143 | ---------------- |
| 144 | |
| 145 | The CPUfreq governor "conservative", much like the "ondemand" |
| 146 | governor, sets the CPU depending on the current usage. It differs in |
| 147 | behaviour in that it gracefully increases and decreases the CPU speed |
| 148 | rather than jumping to max speed the moment there is any load on the |
| 149 | CPU. This behaviour more suitable in a battery powered environment. |
| 150 | The governor is tweaked in the same manner as the "ondemand" governor |
| 151 | through sysfs with the addition of: |
| 152 | |
| 153 | freq_step: this describes what percentage steps the cpu freq should be |
| 154 | increased and decreased smoothly by. By default the cpu frequency will |
| 155 | increase in 5% chunks of your maximum cpu frequency. You can change this |
| 156 | value to anywhere between 0 and 100 where '0' will effectively lock your |
| 157 | CPU at a speed regardless of its load whilst '100' will, in theory, make |
| 158 | it behave identically to the "ondemand" governor. |
| 159 | |
| 160 | down_threshold: same as the 'up_threshold' found for the "ondemand" |
| 161 | governor but for the opposite direction. For example when set to its |
| 162 | default value of '20' it means that if the CPU usage needs to be below |
| 163 | 20% between samples to have the frequency decreased. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 164 | |
| 165 | 3. The Governor Interface in the CPUfreq Core |
| 166 | ============================================= |
| 167 | |
| 168 | A new governor must register itself with the CPUfreq core using |
| 169 | "cpufreq_register_governor". The struct cpufreq_governor, which has to |
| 170 | be passed to that function, must contain the following values: |
| 171 | |
| 172 | governor->name - A unique name for this governor |
| 173 | governor->governor - The governor callback function |
| 174 | governor->owner - .THIS_MODULE for the governor module (if |
| 175 | appropriate) |
| 176 | |
| 177 | The governor->governor callback is called with the current (or to-be-set) |
| 178 | cpufreq_policy struct for that CPU, and an unsigned int event. The |
| 179 | following events are currently defined: |
| 180 | |
| 181 | CPUFREQ_GOV_START: This governor shall start its duty for the CPU |
| 182 | policy->cpu |
| 183 | CPUFREQ_GOV_STOP: This governor shall end its duty for the CPU |
| 184 | policy->cpu |
| 185 | CPUFREQ_GOV_LIMITS: The limits for CPU policy->cpu have changed to |
| 186 | policy->min and policy->max. |
| 187 | |
| 188 | If you need other "events" externally of your driver, _only_ use the |
| 189 | cpufreq_governor_l(unsigned int cpu, unsigned int event) call to the |
| 190 | CPUfreq core to ensure proper locking. |
| 191 | |
| 192 | |
| 193 | The CPUfreq governor may call the CPU processor driver using one of |
| 194 | these two functions: |
| 195 | |
| 196 | int cpufreq_driver_target(struct cpufreq_policy *policy, |
| 197 | unsigned int target_freq, |
| 198 | unsigned int relation); |
| 199 | |
| 200 | int __cpufreq_driver_target(struct cpufreq_policy *policy, |
| 201 | unsigned int target_freq, |
| 202 | unsigned int relation); |
| 203 | |
| 204 | target_freq must be within policy->min and policy->max, of course. |
| 205 | What's the difference between these two functions? When your governor |
| 206 | still is in a direct code path of a call to governor->governor, the |
| 207 | per-CPU cpufreq lock is still held in the cpufreq core, and there's |
| 208 | no need to lock it again (in fact, this would cause a deadlock). So |
| 209 | use __cpufreq_driver_target only in these cases. In all other cases |
| 210 | (for example, when there's a "daemonized" function that wakes up |
| 211 | every second), use cpufreq_driver_target to lock the cpufreq per-CPU |
| 212 | lock before the command is passed to the cpufreq processor driver. |
| 213 | |