CPUfreq and dm-crypt performance problems

Is using CPU frequency scaling on a server a good idea? After all, some servers don’t do very much at night, so why shouldn’t we scale CPU frequency down when servers are idle?

Unfortunately, simple tests revealed serious performance problems when reading from a drive encrypted with dm-crypt / LUKS – here is why (with a simple solution).


First, let’s use “ondemand” governor – reads will be only about ~8 MB/s.

During the test, the CPU was using the lowest frequency possible. However, starting “cat /dev/zero | bzip2 >/dev/null” for a second or two was causing the CPU to switch to the full speed and fast reading.

Now, let’s use performance governor (or, full CPU speed) – we get almost 60 MB/s:

Why is it happening? Does a bell ring somewhere?

“ondemand” CPUfreq governor has a few tunables, described in Documentation/cpu-freq. One of them is up_threshold:

While reading from that dm-crypt device, the following CPU usage was shown on yet another machine (the numbers were consistent across a few tests):

dm-crypt won’t eat the whole CPU power.

With default 80 as up_threshold for “ondemand” governor, no wonder the frequency didn’t scale up.

So a “fix” for this problem was a matter of lowering up_threshold. One more thing as a final note. Some CPUs don’t support lowering their voltage automatically, and the only way to lower CPU frequency is by using throttling. However, throttling won’t save any energy on an idle machine. It’s designed only to cool down a busy CPU by forcing it to HALT from time to time.