I've had multiple people mailing me about this, so I thought I'd make a post just to seed google.

The cpufreq mailing list has moved. It's no longer @linux.org.uk. It has now moved to cpufreq at vger.kernel.org
Subscription is regular majordomo subscribe commands to majordomo at vger..

end of public service announcement.

Linus picked up a bunch of the cpufreq patches I had pending today. Nothing really amazing. Several of them that I had initially queued up for this window got dropped due to regressions, or other forms of failure. Andrew beat me up a little earlier this week for merging a diff that was untested (it spat out an easily-fixed compilation warning), so I spent some time rejigging my merge scripts.

Now, before I merge patches, they have to survive a modular and an allyesconfig build on both x86 and x86-64, and also be clean of checkpatch warnings.

I fear that the initial pain barrier of getting submitters to conform with this may involve lots of hair-tearing, but hopefully it'll pay off in the long run. (One problem we've had with cpufreq submitters in the past is that when asked to resubmit with (for eg) damaged white-space fixed up, the submitters never resubmitted, requiring me to fix it up myself).

cpufreq also seems to be not getting so much attention these days. For sure there's still a bunch of work that needs doing on it, but there's probably 2-3 regular hackers posting patches, and an occasional handful of janitorial hacks sent once per merge window. My own contributions to the code have dropped off somewhat over the last year too, which is something I hope to address soon.

Another problem seems to be that cpufreq is frequently being fingered as responsible for bugs in the last few kernel versions, even when nothing has changed in the code in question. Given the extensive reworking the timer code has undergone in the last few months, I suspect some of the oddball bugs may be a bad interaction, but tracking down such bugs is something of a nightmare. Some drivers are also getting increasingly dependant upon the ACPI doing the right thing. A regression in the interpretation of an ACPI table means a broken cpufreq driver, yet it's not always obvious what is going on.

Sifting through a spec update for Intel CPUs, I found that they've now got some CPUs on the market with IDA (Intel Dynamic Acceleration). From the blurb in the spec..

While one core is inactive, this feature allows one of the processor cores to temporarily operate at a higher frequency point than HFM when the operating system requests increased performance. This higher frequency is called the opportunistic frequency and the HFM frequency is called the guaranteed frequency. The opportunistic frequency has a bus ratio of (N+1):1, where N is the guaranteed frequency bus ratio.

I have no idea how well cpufreq is going to cope with this feature. Len Brown asked at this years power management summit a pointed question along the lines of "What if cpufreq asked for 2GHz, but the CPU actually gave back 2.2GHz"
I guess this is the reason why. Hopefully the CPU won't actually present the higher frequency as an available P-state, but will do it all behind the scenes and run that extra .2GHz if the second core is disabled, we aren't scaled down already, and there's single-threaded work to do.

Likewise, hopefully 'dynamic FSB switching' is also completely transparent.

cpufreq is complex enough already without having to worry about such details :-)