>> 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.
>> Here are my results in GB/s (several averages) for the AMD CPU: ... > but this looks really awful in terms of powersaving. Why? Because sampling often is power consuming? Then what about my Intel CPU which runs at nearly the same max freq and is sampling at 10000 by default? The AMD cpu samples at around 109000 by default when it could sample 10 times more at 10900, like with the Intel one. I think this is about finding the balance between user expectations and power usage (kernel developers wrote that AMD latency for changing freq is really bad). > What about the ignore_nice_load and io_is_busy values? > the latter should be 0 for you on AMD. It is. > /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? No. io_is_busy makes no real difference whether it is set to 1 or 0. Didn't tweek ignore_nice_load though as it shouldn't change the deal IMHO. > Are you sure your results aren't faked by something else going on and > stepping the cpu to a higer frequency? Pretty sure, even if the mesured values may not be really accurate (I got slighly lower values today). What I can't doubt however is that there is a real perf difference when the workaround is used: it's always better. > 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. I agree, but let's use this for good's sake before working for betterness' sake ;) > 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. I agree. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
