Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs

Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs

[Robert Bradbury]

Somewhere in the Linux 2.6.30+ patches was a change to
"arch/x86/kernel/cpu/cpufreq/
p4-clockmod.c" which changed (around line 253) such that
  policy->cpuinfo.transition_latency = 1000000; /* assumed */
became
  policy->cpuinfo.transition_latency = 10000001;

This prevents the ondemand scheduler from being adopted and working
correctly (on a system with the Gnome CPU Frequency Monitor).  The
reports I have received regarding *why* this change was made are
cryptic at best.

I will state that *before* the change CPU frequency scaling did work,
the monitor shows the changes and it is reflected at the wall socket
(measured power consumption on a Pentium IV system dropped from ~135W
to ~105W when ondemand scheduling dropped the CPU frequency from 2.8
GHz down to 350-700 MHz -- which is works fine for most lightly used
but need-to-be-on 24/7 web server systems [1].

This change makes Linux less "green" IMO and I would like to know why
it was implemented and/or if it was implemented without bother to
integrate it with the utility developers that are trying to
develop/manage CPU power use at the user level.  In this day and age,
one should *not* break power consumption reducing features in the O.S.
without significant documentation as to how and why.

It is worth noting that changing this single line of code back does
restore the power conserving features of the "ondemand" scheduler.

Robert

1. For more information see: Gentoo Bug #287463 "Kernel modifications
break ondemand frequency scaling from conserving power" @ the gentoo
bug database (the URL for which was rejected due to LKML security
policies) [2]
2. One would think that the LKML could verify and accept the security
of various bugzilla based bug reporting systems since reporting bugs
this way on the LKML is very, *very* old school.

Re: Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs

[Robert Bradbury]

As Peter Stuge was kind enough to point out the Kernel does indeed
have a bugzilla database.  This problem appears to be related to Bug
#14066 though it doesn't appear to have been fixed.  I've seen several
references which seem to suggest there is some other power manager
than the conservative/ondemand/performance options which the Gnome CPU
Frequency Scaling Monitor utility allows you to use to monitor/adjust
the scheduler used.

If there is I'd greatly appreciate someone telling me what it might be.

Re: Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs

[Matthew Garrett]

The ondemand governor assumes that frequency transitions occur at low 
latency. This isn't usefully the case with p4-clockmod, and running 
ondemand there will generally show obvious performance regressions. If 
you have a recent enough P4 use the acpi-cpufreq driver instead. If not, 
the conservative governor should still work and is a better fit to the 
hardware.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs

[Matthew Garrett]

...except that conservative has the same latency threshold as ondemand, 
which I'm sure wasn't supposed to be the case. I've added the cpufreq 
list to Cc:.

(Summary: p4-clockmod had its latency changed to avoid ondemand using 
it, which was done to avoid the performance impact that ondemand 
generates on p4s. I thought that conservative was still supposed to work 
here, but as it has the same latency threshold it doesn't)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs

[Robert Hancock]

On 10/25/2009 04:46 PM, Robert Bradbury wrote:
> Somewhere in the Linux 2.6.30+ patches was a change to
> "arch/x86/kernel/cpu/cpufreq/
> p4-clockmod.c" which changed (around line 253) such that
>    policy->cpuinfo.transition_latency = 1000000; /* assumed */
> became
>    policy->cpuinfo.transition_latency = 10000001;
>
> This prevents the ondemand scheduler from being adopted and working
> correctly (on a system with the Gnome CPU Frequency Monitor).  The
> reports I have received regarding *why* this change was made are
> cryptic at best.

p4-clockmod is NOT true CPU frequency scaling, it just forces the CPU to 
idle on a periodic duty cycle and has no effect on CPU frequency. The 
clock modulation feature is basically just engaging the same mechanism 
the CPU uses to reduce heat output when it gets too hot, and which is 
not meant as a power saving mechanism. When engaged, it does reduce heat 
output and power usage, but not as much as it reduces system 
performance, and means the system will simply take longer to return to 
idle. In short, using p4-clockmod can only increase power usage in any 
real workload.

If your system and CPU actually support CPU frequency scaling then 
p4-clockmod isn't the driver that should be being used, acpi-cpufreq is 
the one on most systems.