Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- CPU frequency and voltage scaling code in the Linux(TM) kernel
- L i n u x C P U F r e q
- C P U F r e q G o v e r n o r s
- - information for users and developers -
- Dominik Brodowski <linux@brodo.de>
- some additions and corrections by Nico Golde <nico@ngolde.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.
- Contents:
- ---------
- 1. What is a CPUFreq Governor?
- 2. Governors In the Linux Kernel
- 2.1 Performance
- 2.2 Powersave
- 2.3 Userspace
- 2.4 Ondemand
- 2.5 Conservative
- 2.6 Interactive
- 2.7 MinMax
- 2.8 SmartassV2
- 3. The Governor Interface in the CPUfreq Core
- 1. 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}
- 2. Governors In the Linux Kernel
- ================================
- 2.1 Performance
- ---------------
- The CPUfreq governor "performance" sets the CPU statically to the
- highest frequency within the borders of scaling_min_freq and
- scaling_max_freq.
- 2.2 Powersave
- -------------
- The CPUfreq governor "powersave" sets the CPU statically to the
- lowest frequency within the borders of scaling_min_freq and
- scaling_max_freq.
- 2.3 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.
- 2.4 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 usage 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.
- 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.
- 2.5 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.
- 2.6 Interactive
- ---------------
- The CPUfreq governor "interactive" is designed for latency-sensitive,
- interactive workloads. This governor sets the CPU speed depending on
- usage, similar to "ondemand" and "conservative" governors. However,
- the governor is more aggressive about scaling the CPU speed up in
- response to CPU-intensive activity.
- Sampling the CPU load every X ms can lead to under-powering the CPU
- for X ms, leading to dropped frames, stuttering UI, etc. Instead of
- sampling the cpu at a specified rate, the interactive governor will
- check whether to scale the cpu frequency up soon after coming out of
- idle. When the cpu comes out of idle, a timer is configured to fire
- within 1-2 ticks. If the cpu is very busy between exiting idle and
- when the timer fires then we assume the cpu is underpowered and ramp
- to MAX speed.
- If the cpu was not sufficiently busy to immediately ramp to MAX speed,
- then governor evaluates the cpu load since the last speed adjustment,
- choosing th highest value between that longer-term load or the
- short-term load since idle exit to determine the cpu speed to ramp to.
- There is only one tuneable value for this governor:
- min_sample_time: The minimum amount of time to spend at the current
- frequency before ramping down. This is to ensure that the governor has
- seen enough historic cpu load data to determine the appropriate
- workload. Default is 80000 uS.
- 2.7 MinMax
- ---------------
- The CPUfreq governor "maxmin" tries to minimize the frequency jumps by limiting
- the selected frequencies to only two frequencies: either the min or the max
- frequency of the current policy. The frequency is raised or lowered according
- to the current load and the 'up_threshold' and 'down_threshold'.
- Its parameters and implementation are similar to that of conservative.
- It does not have the freq_step parameter as it jumps right from min to max
- and vice-versa.
- The sampling_down_factor, unlike conservative, will count the minimal number
- of samplings since the last time we saw the 'up_threshold' load on the CPU.
- Hence it is set to higher default and acts as a limiter not to do too many
- frequency jumps without hurting the performance.
- 2.8 SmartassV2
- ---------------
- The CPUfreq governor "smartassV2", like other governors, aims to balance
- performance vs battery life by using low frequencies when load is low and
- ramping the frequency when necessary, fast enough to ensure responsiveness.
- The implementation of the governor is roughtly based on the idea of interactive.
- The idle loop is used to track when the CPU has idle cycles. The idle loop will
- set a relatively high rate timer to sample the load when appropriate, the timer
- will measure the load since it was set and schedule a work queue task to do the
- actual frequency change when necessary.
- The most important tunable is the "ideal" frequency: this governor will aim
- for this frequency, in the sense that it will ramp towards this frequency much
- more aggresively than beyond it - both when ramping up from below this frequency
- and when ramping down from above this frequency. Still, note, that when load is
- low enough the governor should choose the lowest available frequency regardless
- of the ideal frequency and similarly when load is consistently high enough the
- highest available frequency will be used.
- Smartass also tracks the state of the screen, and when screen is off (a.k.a
- sleep or suspended in the terms of this governor) a different ideal frequency
- is used. This is the only difference between the screen on and screen off
- states. Proper tuning of the awake_ideal_freq and sleep_ideal_freq should
- allow both high responsiveness when screen is on and utilizing the low
- frequency range when load is low, especially when screen is off.
- Finally, smartass is a highly customizable governor with almost everything
- tweakable through the sysfs. For a detailed explaination of each tunable,
- please see the inline comments at the begging of the code (smartass2.c).
- 3. 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.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement