The majority of modern CPUs that support CPU scaling now use a common driver (acpi-cpufreq). Judging by the search queries that hit my blog, and the amount of mail I get on the subject, there is a failure mode of this driver that many people are hitting, that there isn’t a great deal of information on.

The failure mode looks like this:

$ modprobe acpi-cpufreq
FATAL: Error inserting (/lib/modules/…/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device

Not particularly informative. We don’t spit out anything helpful to dmesg either. So what is the cause of this problem?
In many cases, /proc/cpuinfo shows the cpu supports speedstep (the ‘est’ flag). The answer in nearly all of these cases is.. The BIOS. The ACPI tables in the BIOS list which P-states a particular CPU supports. If your CPU was manufactured after your BIOS was written, you’re probably going to be out of luck. Sometimes, there are BIOS updates on the motherboard manufacturers website that will add support for newer processors. Sometimes we aren’t so lucky. In these cases, we’re out of luck, there’s nothing we can do.

There is another possibility for the error message above: kernel bugs. We have introduced bugs in the ACPI interpretor in the past which have broken parsing of the P-states on some platforms. These kinds of bugs tend to get noticed very quickly, and fixed in equally short time, but it’s worth making a point that it’s important to be running on the last kernel version before reporting bugs.

In 2.6.29, the p4-clockmod cpufreq driver has been changed so that it no longer exports a cpufreq interface to sysfs.
This will no doubt have some people complaining that they can no longer change their CPU frequency.

The thing is, they never could.

From a recent posting to the cpufreq list:

I have a laptop (ASUS W7J) with an Intel Core2 T7200 2GHz.
…
When I use the p4-clockmod, I get:

available frequency steps: 250 MHz, 500 MHz, 750 MHz, 1.00 GHz, 1.25 GHz, 1.50 GHz, 1.75 GHz, 2.00 GHz
…

For every one of those ‘frequency’ options, the CPU is actually running at 2GHz. It never changes speed. Not at all.
The p4-clockmod driver abuses the cpufreq interface to expose a clock modulation feature that has been in processors for a long time. (Even the earlier pentiums had a variant of it). The driver modulates the clock applied to the processor so that instead of every clock cycle meaning the processor gets do some work, only a percentage of the clocks make the CPU do real work. The remainder of the time, the processor just sits there.

So the 1.00GHz ‘frequency’ is actually “run at 2GHz, but only do work 50% of the time”.

On the surface, this sounds like a good idea. The other 50%, the CPU is idle, so you’re saving power, right?
Not so much. In fact, you could be burning more power. The reason for this is that when the processor is sitting there doing nothing, it isn’t lower frequency, and more importantly, it very likely isn’t entering C states. So you’re burning the same amount of power, but now you’re only doing work for 50% of the time. As a result of this, your workload takes twice as long to complete.

If it isn’t saving any power, what is the point of this at all ?
A clue is revealed by reading the Intel programmers guide for this feature; it’s closely tied to the processors thermal monitoring feature. The idea of this feature is that when the CPU overheats, it can ‘back off’ a little, to prevent overheating. The temperature of a processor isn’t constant. When running flat out, it will generate more heat. So by modulating the clock, the maximum amount of heat possible to generate decreases.

The changes merged into the 2.6.29rc kernel remove the user-visible interface, and replace it with direct calls from the ACPI code that gets triggered on thermal events. It’s all entirely automatic now.