Bug 119385

Summary: "Dynamic" CPU frequency policy in powersave does not work well
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Daniel Wolstenholme <daniel>
Component: BasesystemAssignee: Thomas Renninger <trenn>
Status: RESOLVED INVALID QA Contact: E-mail List <qa-bugs>
Severity: Critical    
Priority: P5 - None CC: venkatesh.pallipadi
Version: RC 1   
Target Milestone: ---   
Hardware: i686   
OS: All   
Whiteboard:
Found By: Customer Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Daniel Wolstenholme 2005-09-29 05:14:01 UTC
My system is a 3.6GHz Pentium 4.  I installed 10.0 RC1 and am using the 
default kernel.  Everything was very slow; there's a few comments here from me 
about this.  I finally figured out that my CPU was running at 450 MHz most of 
the time, which explains why it seemed like it was about as fast as my old 
Celeron 300 MHz. 
 
Upon more investigation, I found that my powersave daemon was set to use the 
"dynamic" CPU frequency policy (accessible through the KDE Kpowersave applet 
in the toolbar).  Messing with it some more, and looking at the output of the 
"cpufreq-info" while putting a load on the system, I found that the CPU 
frequency did indeed seem to be jumping around as the load varied, even up to 
3.6 GHz, but only for very short bursts, and then back down to 450 MHz. 
 
The overall effect seems to be very little visible performance improvement 
over the "powersave" policy, which just holds it at 450 MHz.  Everything is 
dog slow.  To me, this makes the "dynamic" policy utterly useless. 
 
I'd like to use dynamic frequency scaling, assuming it actually does save 
power (why else would it be there?), because there's many times I'm not doing 
much on the computer, or leave it on overnight, etc., but this level of 
performance is totally unacceptable. 
 
It seems to me the powersave daemon should have far more delay in changing the 
frequency: when a load reduction is detected, the frequency should be set to 
maximum and left there while the user is doing things.  After the load drops 
to near 0% for 10 seconds or so, it can then start scaling down.  The user 
shouldn't see much if any performance degradation compared to the full-speed 
mode.
Comment 1 Thomas Renninger 2005-10-06 14:03:07 UTC
Is Hyperthreading enabled?
Does it help if you set CPUFREQ_CONTROL="" to CPUFREQ_CONTROL="userspace" in
/etc/sysconfig/powersave/cpufreq and restart the powersave daemon ("rcpowersave
restart")?

If both is true, does it help if you disable hyperthreading in BIOS and use
CPUFREQ_CONTROL="kernel" -> do not forget to restart the powersave daemon again.

Hmmm, Pentium 4 3.6 GHz going down to 450 MHz seems to me as Intel is faking
speedstep with throttling through ACPI abstraction?!?
Comment 2 Forgotten User ZhJd0F0L3x 2005-10-06 14:14:07 UTC
what cpufreq driver are you using? on boot, there should be a line like
"rcpowersaved: enter 'speedstep_centrino' into CPUFREQD_MODULE in
/etc/sysconfig/powersave/cpufreq."
in /var/log/messages. (probably not speedstep_centrino, but the module used on
your machine, just grep for CPUFREQD_MODULE in /var/log/messages).
Comment 3 Venkatesh Pallipadi 2005-10-06 15:10:34 UTC
Probably p4-clockmod driver is getting used here today?

I haven't seen P4 3.6GHz system running at 450 MHz with speedstep-centrino or
acpi-cpufreq driver. The minimum frequency with those two drivers should be
around 2.8GHz.
Comment 4 Thomas Renninger 2005-10-06 15:26:39 UTC
OK, we should remove the p4-clockmod driver from our distri. People are getting
confused and think it helps to save power, but it already is used through
/proc/acpi/processor/.../throttling and there could happen bad things if both
interfaces are used as it is probably the case here.

I will close this one as invalid in case you have used the p4-clockmod driver.
Reopen the bug if you have not.