diff options
| author | Dave Jones <davej@redhat.com> | 2005-05-31 19:03:47 -0700 |
|---|---|---|
| committer | Dave Jones <davej@redhat.com> | 2005-05-31 19:03:47 -0700 |
| commit | b9170836d1aa4ded7cc1ac1cb8fbc7867061c98c (patch) | |
| tree | 87fbac643c392c8ba2459158f78671c356e8dd4a /drivers/cpufreq/Kconfig | |
| parent | b53cc6ead046093477ec7a3354d620337101ea5b (diff) | |
| download | kernel_samsung_smdk4412-b9170836d1aa4ded7cc1ac1cb8fbc7867061c98c.zip kernel_samsung_smdk4412-b9170836d1aa4ded7cc1ac1cb8fbc7867061c98c.tar.gz kernel_samsung_smdk4412-b9170836d1aa4ded7cc1ac1cb8fbc7867061c98c.tar.bz2 | |
[CPUFREQ] Conservative cpufreq governer
A new cpufreq module, based on the ondemand one with my additional patches
just posted. This one is more suitable for battery environments where its
probably more appealing to have the cpu freq gracefully increase and decrease
rather than flip between the min and max freq's.
N.B. Bruno Ducrot pointed out that the amd64's "do have unacceptable latency
between min and max freq transition, due to the step-by-step requirements
(200MHz IIRC)"; so AMD64 users would probably benefit from this too.
Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk>
Signed-off-by: Dave Jones <davej@redhat.com>
Diffstat (limited to 'drivers/cpufreq/Kconfig')
| -rw-r--r-- | drivers/cpufreq/Kconfig | 20 |
1 files changed, 20 insertions, 0 deletions
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 3617e15..60c9be9 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -119,4 +119,24 @@ config CPU_FREQ_GOV_ONDEMAND If in doubt, say N. +config CPU_FREQ_GOV_CONSERVATIVE + tristate "'conservative' cpufreq governor" + depends on CPU_FREQ + help + 'conservative' - this driver is rather similar to the 'ondemand' + governor both in its source code and its purpose, the difference is + its optimisation for better suitability in a battery powered + environment. The frequency is gracefully increased and decreased + rather than jumping to 100% when speed is required. + + If you have a desktop machine then you should really be considering + the 'ondemand' governor instead, however if you are using a laptop, + PDA or even an AMD64 based computer (due to the unacceptable + step-by-step latency issues between the minimum and maximum frequency + transitions in the CPU) you will probably want to use this governor. + + For details, take a look at linux/Documentation/cpu-freq. + + If in doubt, say N. + endif # CPU_FREQ |