On Sun, Feb 20, 2011 at 06:35:53PM +0100, Fabien C. wrote:
> Package: cpufrequtils
> Version: 007-1
> Severity: wishlist
> Tags: patch
>
> Hello,
>
> Some CPUs (particularly from AMD) have a very high latency for frequency
> changes. This is visible at the user level and can lead the user to change
> it's
> cpufreq governor to performance, thus wasting energy.
...
> Here is the bad guy:
>
> AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
> Down freq: 1000MHz / Up freq: 2200MHz
>
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:109000
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate_min:10900
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:109000
>
> And on my (nice) Intel system, I got these:
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:10000
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate_min:10000
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:10000
the concept is that it makes no sense to sample cpu usage _while_
stepping the cpu frequency and with sampling_rate set to the minimum it
will happen 10 times.
> For testing, I simply ran the following command and compared transfer rates
> (GB/s):
> dd if=/dev/zero of=/dev/null bs=300k count=1000
>
> Or (using zsh) the following can give me an average rate on 50 samples:
> moy=0 ; for val in `i=50 ; while [ $i -gt 0 ] ; do nice -n -19 dd if=/dev/zero
> of=/dev/null bs=300k count=1000 2>&1 | tail -n 1 | awk '{print $8}' | sed
> s/,/\./ ; sleep 0.5 ; i=$(($i-1)) ; done` ; do moy=$(($moy+$val)) ; done ;
> echo
> $(($moy/50.))
>
> Here are my results in GB/s (several averages) for the AMD CPU:
> --------------
> performance :
> 7.61 / 7.61 / 7.61 / 7.56 / 7.37
>
> ondemand (no-tweaking) :
> 4.83 / 4.68 / 4.73 / 5.14 / 5.51 / 5.37
>
> ondemand (sampling_rate = rampling_rate_min, i.e. default/10) :
> 7.00 / 7.07 / 7.03 / 7.06 / 7.02 / 7.01 / 7.04
> --------------
but this looks really awful in terms of powersaving.
What about the ignore_nice_load and io_is_busy values?
the latter should be 0 for you on AMD.
/sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0
/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:1
Any better results tweaking these?
Are you sure your results aren't faked by something else going on and
stepping the cpu to a higer frequency?
> Changing sampling_rate seems to be worth the patch. So my patch adds an option
> to the init.d/cpufrequtils for tweeking sampling_rate (set it to the s_r_min)
> if it detects a slow transitioning CPU.
>
> It is not very intrusive because disabled by default, and even when enabled,
> tries to detect a slow CPU before tweeking anything (safemode).
it looks useful. It would be nice to make it more generic at this point
and allow tweaking all the values if they are available for the selected
governor.
> This said, having such a bad default sampling_rate may be a kernel bug. What
> do
> you think?
I think the issue should be reported to the cpufreq development mailing
list if you have a case worth looking into. Independently of the patch
to debian's init scripts.
Thanks!
--
mattia
:wq!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
