Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs
in [Kernel]
|
Prev: User return notifiers / just-in-time MSR switching for KVM
Next: pci: pciehp update the slot bridge res to get big range for pcie devices
From: Robert Bradbury on 25 Oct 2009 18:50 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 26 Oct 2009 08:00 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 26 Oct 2009 14:20 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 26 Oct 2009 14:30 ....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 26 Oct 2009 20:50
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/ |