CPUFreq Ondemand Could Be Faster, Use Less Power With Linux 3.17

Improvements to the CPUfreq ondemand governor could lead to faster performance in low to medium workloads with the Linux 3.17 kernel while also consuming less power overall.

Queued up today for merging into the Linux 3.17 kernel in a few weeks time are two patches that for the CPUfreq driver's ondemand governor will eliminate a "deadband effect" in low workloads. Stratos Karafotis -- the author of these patches -- explained, "This patchset changes slightly the calculation of target frequency to eliminate the deadband effect (explained in patch 2 changelog) that it seems to slow down the CPU in low and medium loads."

Tests were done by the developer of the patches and the benchmarks were carried out with the Phoronix Test Suite on an Intel Core i7 machine. With workloads ranging from the Linux kernel compilation to Apache to FFmpeg the energy savings were up to 4% while the performance was up to 6% faster with CPUfreq ondemand. Those details can be found in this mailing list post.

Rafael J. Wysocki, the Intel employee that serves as the ACPI/PM subsystem maintainer for the Linux kernel, queued the patches today for merging into Linux 3.17. Below is the patch message that describes this CPUfreq ondemand change for eliminating the deadband effect.

Currently, ondemand calculates the target frequency proportional to load using the formula:

Target frequency = C * load
where C = policy->cpuinfo.max_freq / 100

Though, in many cases, the minimum available frequency is pretty high and the above calculation introduces a dead band from load 0 to 100 * policy->cpuinfo.min_freq / policy->cpuinfo.max_freq where the target frequency is always calculated to less than policy->cpuinfo.min_freq and the minimum frequency is selected.

For example: on Intel i7-3770 @ 3.4GHz the policy->cpuinfo.min_freq = 1600000 and the policy->cpuinfo.max_freq = 3400000 (without turbo). Thus, the CPU starts to scale up at a load above 47. On quad core 1500MHz Krait the policy->cpuinfo.min_freq = 384000 and the policy->cpuinfo.max_freq = 1512000. Thus, the CPU starts to scale at load above 25.

Change the calculation of target frequency to eliminate the above effect using the formula:

Target frequency = A + B * load
where A = policy->cpuinfo.min_freq and
B = (policy->cpuinfo.max_freq - policy->cpuinfo->min_freq) / 100

This will map load values 0 to 100 linearly to cpuinfo.min_freq to cpuinfo.max_freq.

Also, use the CPUFREQ_RELATION_C in __cpufreq_driver_target to select the closest frequency in frequency_table. This is necessary to avoid selection of minimum frequency only when load equals to 0. It will also help for selection of frequencies using a more 'fair' criterion.