wok-next diff linux/description.linux-cpufreq.txt @ rev 21727

created recipe for vbindiff
author Hans-G?nter Theisgen
date Sat Nov 21 14:32:44 2020 +0100 (2020-11-21)
parents 119e586fb823
children
line diff
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/linux/description.linux-cpufreq.txt	Sat Nov 21 14:32:44 2020 +0100
     1.3 @@ -0,0 +1,44 @@
     1.4 +CPU Frequency scaling
     1.5 +
     1.6 +CPU Frequency scaling allows you to change the clock speed of CPUs on the fly.
     1.7 +This is a nice method to save power, because the lower the CPU clock speed, the
     1.8 +less power the CPU consumes.
     1.9 +
    1.10 +Note that this driver doesn't automatically change the CPU clock speed, you
    1.11 +need to either enable a dynamic cpufreq governor (see below) after boot, or use
    1.12 +a userspace tool.
    1.13 +
    1.14 +  * 'performance' governor
    1.15 +    This cpufreq governor sets the frequency statically to the highest
    1.16 +    available CPU frequency.
    1.17 +  * 'powersave' governor
    1.18 +    This cpufreq governor sets the frequency statically to the lowest available
    1.19 +    CPU frequency.
    1.20 +  * 'userspace' governor for userspace frequency scaling
    1.21 +    Enable this cpufreq governor when you either want to set the CPU frequency
    1.22 +    manually or when a userspace program shall be able to set the CPU
    1.23 +    dynamically, like on LART <http://www.lartmaker.nl/>.
    1.24 +  * 'ondemand' cpufreq policy governor
    1.25 +    'ondemand' - This driver adds a dynamic cpufreq policy governor. The
    1.26 +    governor does a periodic polling and changes frequency based on the CPU
    1.27 +    utilization. The support for this governor depends on CPU capability to do
    1.28 +    fast frequency switching (i.e, very low latency frequency transitions).
    1.29 +  * 'conservative' cpufreq governor
    1.30 +    'conservative' - this driver is rather similar to the 'ondemand' governor
    1.31 +    both in its source code and its purpose, the difference is its optimisation
    1.32 +    for better suitability in a battery powered environment. The frequency is
    1.33 +    gracefully increased and decreased rather than jumping to 100% when speed
    1.34 +    is required.
    1.35 +    If you have a desktop machine then you should really be considering the
    1.36 +    'ondemand' governor instead, however if you are using a laptop, PDA or even
    1.37 +    an AMD64 based computer (due to the unacceptable step-by-step latency
    1.38 +    issues between the minimum and maximum frequency transitions in the CPU)
    1.39 +    you will probably want to use this governor.
    1.40 +  * 'schedutil' cpufreq policy governor
    1.41 +    This governor makes decisions based on the utilization data provided by the
    1.42 +    scheduler. It sets the CPU frequency to be proportional to the
    1.43 +    utilization/capacity ratio coming from the scheduler. If the utilization is
    1.44 +    frequency-invariant, the new frequency is also proportional to the maximum
    1.45 +    available frequency. If that is not the case, it is proportional to the
    1.46 +    current frequency of the CPU. The frequency tipping point is at
    1.47 +    utilization/capacity equal to 80% in both cases.