Re: CPU scaling problems
On 15/11/12 21:06, Francesco Mazzoli wrote:
> With `conservative' or `performance' the CPU scales up correctly (well, with
> performance it is always scaled up). With `ondemand' it doesn't.
>
> This has noticeable consequences: compiling is slow, flash videos are sluggish.
> So I do have a problem. And I want a governor that scales down my CPU,
> especially on battery. I could stick with `conservative' but I'd like to get to
> the bottom of this since `ondemand' is usually the best option for modern CPUs.
Actually I use 'conservative' over the 'ondemand' governor. It can be
tweaked to react more quickly, close to the speed of 'ondemand', but it
has the nice feature of providing a "cool-down" period during which if
some task comes along and storms the CPU, the CPU is already at maximum
speed, so no need to scale up; this helps with minuscule (but
noticeable) interruptions in multimedia apps (with video is most
noticeable).
Give 'conservative' a try, you might like it.
Here are the values that I use (install 'sysfsutils' and put them in
/etc/sysfs.conf):
---->8--
# by default it's 444, so we have to change permissions to be able to
change values
#mode devices/system/cpu/cpufreq/conservative = 644
devices/system/cpu/cpufreq/conservative/freq_step = 10
devices/system/cpu/cpufreq/conservative/up_threshold = 45
# no need to set ignore_nice_load here. It's set by laptop-mode
#devices/system/cpu/cpufreq/conservative/ignore_nice_load = 1
devices/system/cpu/cpufreq/conservative/sampling_down_factor = 9
devices/system/cpu/cpufreq/conservative/sampling_rate = 120000
---->8--
Also here are some helpful links that I used when I tweaked my
'conservative':
- http://wiki.debian.org/HowTo/CpuFrequencyScaling
- http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html
- https://wiki.archlinux.org/index.php/CPU_Frequency_Scaling
- http://en.gentoo-wiki.com/wiki/CPU_Frequency_Scaling
-
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=Documentation/cpu-freq/governors.txt;h=c7a2eb8450c226b50e55b28f8c6669c6041cc0e3;hb=HEAD
--
Adrian Fita
Reply to: