From: Robert Bradbury on
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Robert Bradbury on
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on
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(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on
....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(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/