| rev |
line source |
|
Hans-G?nter@1217
|
1 CPU Frequency scaling
|
|
Hans-G?nter@1217
|
2
|
|
Hans-G?nter@1217
|
3 CPU Frequency scaling allows you to change the clock speed of CPUs on the fly.
|
|
Hans-G?nter@1217
|
4 This is a nice method to save power, because the lower the CPU clock speed, the
|
|
Hans-G?nter@1217
|
5 less power the CPU consumes.
|
|
Hans-G?nter@1217
|
6
|
|
Hans-G?nter@1217
|
7 Note that this driver doesn't automatically change the CPU clock speed, you
|
|
Hans-G?nter@1217
|
8 need to either enable a dynamic cpufreq governor (see below) after boot, or use
|
|
Hans-G?nter@1217
|
9 a userspace tool.
|
|
Hans-G?nter@1217
|
10
|
|
Hans-G?nter@1217
|
11 * 'performance' governor
|
|
Hans-G?nter@1217
|
12 This cpufreq governor sets the frequency statically to the highest
|
|
Hans-G?nter@1217
|
13 available CPU frequency.
|
|
Hans-G?nter@1217
|
14 * 'powersave' governor
|
|
Hans-G?nter@1217
|
15 This cpufreq governor sets the frequency statically to the lowest available
|
|
Hans-G?nter@1217
|
16 CPU frequency.
|
|
Hans-G?nter@1217
|
17 * 'userspace' governor for userspace frequency scaling
|
|
Hans-G?nter@1217
|
18 Enable this cpufreq governor when you either want to set the CPU frequency
|
|
Hans-G?nter@1217
|
19 manually or when a userspace program shall be able to set the CPU
|
|
Hans-G?nter@1217
|
20 dynamically, like on LART <http://www.lartmaker.nl/>.
|
|
Hans-G?nter@1217
|
21 * 'ondemand' cpufreq policy governor
|
|
Hans-G?nter@1217
|
22 'ondemand' - This driver adds a dynamic cpufreq policy governor. The
|
|
Hans-G?nter@1217
|
23 governor does a periodic polling and changes frequency based on the CPU
|
|
Hans-G?nter@1217
|
24 utilization. The support for this governor depends on CPU capability to do
|
|
Hans-G?nter@1217
|
25 fast frequency switching (i.e, very low latency frequency transitions).
|
|
Hans-G?nter@1217
|
26 * 'conservative' cpufreq governor
|
|
Hans-G?nter@1217
|
27 'conservative' - this driver is rather similar to the 'ondemand' governor
|
|
Hans-G?nter@1217
|
28 both in its source code and its purpose, the difference is its optimisation
|
|
Hans-G?nter@1217
|
29 for better suitability in a battery powered environment. The frequency is
|
|
Hans-G?nter@1217
|
30 gracefully increased and decreased rather than jumping to 100% when speed
|
|
Hans-G?nter@1217
|
31 is required.
|
|
Hans-G?nter@1217
|
32 If you have a desktop machine then you should really be considering the
|
|
Hans-G?nter@1217
|
33 'ondemand' governor instead, however if you are using a laptop, PDA or even
|
|
Hans-G?nter@1217
|
34 an AMD64 based computer (due to the unacceptable step-by-step latency
|
|
Hans-G?nter@1217
|
35 issues between the minimum and maximum frequency transitions in the CPU)
|
|
Hans-G?nter@1217
|
36 you will probably want to use this governor.
|
|
Hans-G?nter@1217
|
37 * 'schedutil' cpufreq policy governor
|
|
Hans-G?nter@1217
|
38 This governor makes decisions based on the utilization data provided by the
|
|
Hans-G?nter@1217
|
39 scheduler. It sets the CPU frequency to be proportional to the
|
|
Hans-G?nter@1217
|
40 utilization/capacity ratio coming from the scheduler. If the utilization is
|
|
Hans-G?nter@1217
|
41 frequency-invariant, the new frequency is also proportional to the maximum
|
|
Hans-G?nter@1217
|
42 available frequency. If that is not the case, it is proportional to the
|
|
Hans-G?nter@1217
|
43 current frequency of the CPU. The frequency tipping point is at
|
|
Hans-G?nter@1217
|
44 utilization/capacity equal to 80% in both cases.
|