[Bugme-new] [Bug 4379] New: Default sampling rates for ondemand governor are too high on a amd64

[bugme-daemon at osdl.org]

http://bugme.osdl.org/show_bug.cgi?id=4379

           Summary: Default sampling rates for ondemand governor are too
                    high on a amd64
    Kernel Version: 2.6.11
            Status: NEW
          Severity: normal
             Owner: cpufreq at www.linux.org.uk
         Submitter: gpiez at web.de


Distribution: Gentoo   
Hardware Environment: AMD Athlon(tm) 64 Processor 3200+, Clawhammer, 754   
Software Environment:   
Problem Description: Default sampling rates for ondemand governor are too high 
on a amd64. This leads to bad responsivness for desktop apps.  
   
Steps to reproduce: 
 
I gave the ondemand governor a try and noticed a slow system (bad 
responsivness).  
  
The frequencies/voltages seemed to switch fine, so I wondered where this slow 
feeling came from.  
 
I tried  
  
# watch -n 0.1 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq  
  
and watched the output while starting "kdevelop" (huge, bloated, very nice 
app). With max frequency this needs something about 3 seconds to start, if 
everything is in the disk cache. Now it needed 5-6 seconds. I noticed the 
frequency didn't go up at the the moment I started it, but about 1-2 seconds 
later, when app was almost loaded.  
Further investigating, I inspected the values 
at /sys/devices/system/cpu/cpu0/cpufreq/ondemand .  
  
It turns out, that on my system (clawhammer 754, 2 GHz, 1MB 2nd Level Cache) 
the default sampling rates are quite high:  
 
ondemand # cat sampling_rate  
1240000  
ondemand # cat sampling_down_factor  
10  
  
Which means, for a frequency transition upwards, the cpu usage is sampled 
every 1,24 seconds, for scaling downwards every 12,4 (!) seconds. Which means, 
every action which needs less than about a second (for instance opening a 
konqueror window) is likely to be done at slow speed (800 MHz in my case), 
others, which take longer than the sampling period, get fullspeed only after a 
noticable latency, and so, need up to 3 seconds longer to complete (1,24 
seconds * 2.5 speed factor). Which was exactly what i observed. 
 
Additionally, the scaling down takes 12,4 seconds, during the this time the 
cpu will burn with 2 GHz doing essentially nothing. This is a unneccessary 
power consumption. 
 
I think sampling_rate_min and sampling_rate_max are way too high. What use may 
a 620 second sampling time have? On the other hand, it can't be faster than 
0,62 s which reduces the lag to 1.5 seconds. For me this is not sufficient. 
 
The intel cpus seem to have faster transition times (by a factor of 10), in 
this case, the effect is probably not noticable. 
 
I suggest a fixed default sampling time (say like 50 ms), making it a factor 
(currently 1000) of cpuinfo.transition_latency leads to bad behavior, if the 
transition latency is not in the "intel range". The value of sampling_rate_min 
should be adjusted downwards.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.