darkness

I spent pretty much the entire day working feverishly at getting support for /proc/cpufreq into the 2.4 kernel. /proc/cpufreq allows you to tinker with the processor speed on those systems that allow it, like my ThinkPad T40 with Pentium M (Centrino) processor.

In short: this was a royal pain in the nuts. I tried several patches, fixed several more… whine whine whine. I eventually ended up making a patch against Red Hat’s 2.4.20-20.9 kernel RPM. This kernel, by default, will not work on a (or, at least, my) Centrino processor. I’ve posted my patch for /proc/cpufreq against RH kernel-2.4.20-20.9 and kernel-2.4.20-20.9+codefu.1, containing Centrino SpeedStep support. Both of these are using the cpufreq snapshot (I think) from 2003-09-09. It took me for-fucking-ever to find this. Along the way I also found http://www.codemonkeys.org.uk/projects/cpufreq/ which appears to have some patches for this against specific kernel versions (and may be too old, as of this writing, to support my processor) and what I suspect is the origin of the cpufreq stuff, or at least a CVS repository for it, at http://www.arm.linux.org.uk/cvs/. Scary, scary stuff. One bug I’ve noticed: I have to write a command to /proc/cpufreq twice for /proc/cpuinfo to reflect it, and by inference (and testing with time perl -e 'for($i=0;$i<10000000;$i++){}') for the change to take effect. For example, echo '0%42%42%userspace' >/proc/cpufreq the first time and no change reflected in /proc/cpuinfo, perl still running fast (assuming it was at 100% of speed prior to the command). echo again, and everything reflects the new lower speed. This might just be with the userspace governor; I didn’t test other governors except to note that they work. I might be using this governor wrong, in fact.

I installed cpudyn RPMs and it really seems to be working quite nicely thus far. Its polling seems to generate nothing noticeable in top, and it’s very responsive.