Comment 21 for bug 107545

I can change sampling_rate to 40000 with the 2.6.28-12 kernel, but not the 2.6.30-rc7 kernel. Values equal to or above 80000 are fine.

This behaviour looks to be deliberate in 2.6.30 - cpufreq_ondemand.c has this in it:

/* Above MIN_SAMPLING_RATE will vanish with its sysfs file soon
 * Define the minimal settable sampling rate to the greater of:
 * - "HW transition latency" * 100 (same as default sampling / 10)
 * - MIN_STAT_SAMPLING_RATE
 * To avoid that userspace shoots itself.
*/
static unsigned int minimum_sampling_rate(void)
{
 return max(def_sampling_rate / 10, MIN_STAT_SAMPLING_RATE);
}

so the kernel must be calculating a minimum of 80000 for my processor (Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz). It's the same on another PC with a Pentium M @ 1.7 GHz.

The main reason I've been looking at changing from the defaults is that after rebooting, I get good performance, but after running for some hours, the system becomes reluctant to switch quickly to max freq (my test case is running a game under wine; it runs typically at 90-120% CPU as reported by top, and even with up_threshhold set to 80, the CPU mostly stays stuck at 800MHz, and the frame rates suck). I get this with the stock kernel as well as the 2.6.30 kernel.