Disable "ondemand" CPU scaling daemon

Ubuntu prior to 18.04

Instead of disabling execution of the /etc/init.d/ondemand (as suggested by George) script you should use the this command

sudo update-rc.d ondemand disable

To make the init system not start the script, this is the recognized way of doing it! Disabling the exec permission (sudo chmod -x /etc/init.d/ondemand) might be overwritten if the package is updated.

Ubuntu 18.04+

Ubuntu relocated this script to ondemand.service which execute /lib/systemd/set-cpufreq; use this command to disable the service

~$ sudo systemctl disable ondemand
Removed /etc/systemd/system/multi-user.target.wants/ondemand.service.

Frequency scaling isn't static. As soon as there is work to do, the CPU hops into action, P states boost up, and everything flies.

It's enabled because it's widely seen as a good thing. Saves you energy (good for your wallet and the environment). Keeps heat down (so important in a server room). And it's pretty unnoticeable.

Moreover on modern Intel chips, if you have scaling on you can use "turbo boost" where one core will run at higher-than-stock speeds for a time. This is very useful for spikes of single-threaded work. Without scaling enabled, you don't get this.

Set all CPUs to performance governor:

for GOVERNOR in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; \
do \
    echo "performance" | sudo tee $GOVERNOR; \
done

All supported governors by Linux kernel:

• performance Run the CPU at the maximum frequency.
• powersave Run the CPU at the minimum frequency.
• userspace Run the CPU at user specified frequencies.
• ondemand Scales the frequency dynamically according to current load. Jumps to the highest frequency and then possibly back off as the idle time increases.
• conservative Scales the frequency dynamically according to current load. Scales the frequency more gradually than ondemand.
• schedutil Scheduler-driven CPU frequency selection

See https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt

On some systems, the 'ondemand' governor is unfortunately broken.

This is the case for "Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz" and kernel 2.6.32-42.

The kernel thinks it can set the frequency individually for each CPU while the hardware actually only allows setting the frequency on groups of several CPUs (e.g. CPU 0 and 1 together, and CPU 2 and 3 together).

You may find out that the kernel isn't aware of this by looking at the /sys/devices/system/cpu/cpu*/cpufreq/affected_cpus files which contain "0", "1", "2", "3" instead of "0 1", "0 1", "2 3", "2 3".

The visible effect of this missmatch is a single-threaded process that starts running full speed on one CPU (the 'ondemand' governor reacts fast), and then, after about 20 seconds (depends on setting details), looses some of its speed.

The reason is the OS, with the 'ondemand' governor, periodically reapplies low freqs on the idle CPUs, not expecting that it will also implicitly change the freq of our busy CPU. It's not even visible when you look at /sys/devices/system/cpu/cpu*/cpufreq/*cur_freq or /proc/cpuinfo, the OS is just not aware of it!

So, on these systems the solution is to switch back to the simple 'performance' governor.

PS: In my case, running the CPUs constantly at their full freq didn't change anything concerning fan noise. I suppose when a CPU is idling, a lower or higher frequency will not have much impact on its power usage.

You could install the rcconf debian tool:

sudo apt-get install rcconf

then disable the "ondemand" service from there.