Comment 9 for bug 432706

This has been deliverately broken in recent kernel as it's been deemed "too slow" for us to carry on using. If like me you disagree, you can reverse the change quite easily if you're building your own kernel/modules, I'll try and post these details to where I can find people who've hit the same problem and want to undo the change.

If you run:
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency
you will notice the latency is 10000001, which I thought looked highly suspicously like someone had hardcoded that number somewhere to be 1 more than a max number set somewhere where the ondemand/etc would work. You can find it in the file (assuming kernel sources are in /usr/src/linux) :

/usr/src/linux/arch/x86/kernel/cpu/cpufreq/p4-clockmod.c

If you search in that file for the number 10000001 in that file, decrease it by one to 10000000, and recompile the module (if you have p4-clockmod compiled as a module; if it's linked into the kernel you'll need to recompile the kernel and reboot).

I have found that changing the up_threshold of the ondemand governor from its default to 40 makes it ramp its speed up when I need it to, and stay there until it drops back down again. With my usage pattern it's not making these switches very often, so any delays in changing the speed are perfectly acceptable -to me-. To do this, simply:
echo 40 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

Hope there's someone out there this helps. Oh, and of course, yay for open source! We don't have to someone telling us we can't do something with our own computer cuz they don't think it's fast enough! :-)