Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs

From: Robert Bradbury
Date: Sun Oct 25 2009 - 18:46:13 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/