Set Intel Performance Bias Safely with cpupower

cpupower set writes a chosen performance-bias value to supported Intel processors, and this guide covers checking what the hardware actually accepted.

The setting is a hint: 0 favours maximum performance and 15 favours maximum energy efficiency. It does not replace P-states or C-states.

Allow about 10 minutes. You need a supported Intel processor, the linux-tools-common package and the matching kernel-specific Linux tools. Changing the bias needs root privileges. Reading it normally does not, although access to the relevant interface can vary with the system.

1. Check the installed tool before changing anything

First check which executable is being selected and ask for its version. These commands do not change processor settings.

$ command -v cpupower
$ cpupower --version

On the system used for this guide, linux-tools-common is version 6.8.0-139.139. Its /usr/bin/cpupower wrapper looks for tools matching the running kernel. Here, the matching executable is absent, so the command prints a warning naming linux-tools-6.8.0-139-generic and exits with status 2. Install the already-approved, matching tools for your kernel before continuing. Do not treat the wrapper's warning as evidence that the setting is unsupported.

2. Read the current bias and support status

Use cpupower info -b to inspect the current value. The information command displays core zero by default. To inspect every core, use the global CPU selector.

$ cpupower info -b
$ cpupower -c all info -b

Record the value before changing it. The command also helps show whether the feature is supported at all. If it reports that the feature is unavailable, stop here: a missing feature cannot be repaired by trying more values.

The performance-bias operation needs the msr kernel driver, built as CONFIG_X86_MSR. Check whether it is loaded without changing the bias:

$ lsmod | grep '^msr\b'

If there is no output and you have confirmed that the running kernel provides the driver, load it with elevated privileges:

$ sudo modprobe msr
$ lsmod | grep '^msr\b'

If modprobe cannot find msr, use the kernel and tools supplied for that system rather than forcing an unrelated module. The reversible recovery is to unload it later with sudo modprobe -r msr, provided no other workload needs it.

3. Choose and record a value

Pick a value from 0 to 15. Use 0 when performance is the priority, 15 when energy efficiency is the priority, or an intermediate value for a compromise. This is a hardware policy hint, not a fixed CPU frequency control.

Save the old value from step 2 before applying the new one. The example below uses 5 as an obvious placeholder. Replace it with your chosen value, and keep the old value in your change record so that you can undo the change.

4. Apply the value to all CPUs

By default, cpupower set applies settings to all cores. This changes live processor behaviour, so run it during a maintenance window if workload performance or energy use matters.

$ sudo cpupower set -b 5

A successful command may produce no output. That silence is not verification. Read the value again:

$ cpupower -c all info -b

Do not assume that a value written for one CPU stays isolated. The manpage warns that hardware restrictions can make a change on one CPU affect related CPUs, such as other CPUs on the same socket.

5. Target a CPU range only when you need to

Use the global -c option when a smaller CPU set is intentional. This example targets CPUs 0 through 3:

$ sudo cpupower -c 0-3 set -b 5
$ cpupower -c 0-3 info -b

Other accepted list forms include all, 0-7:2 for every second CPU in that range, and comma-separated values such as 1,3,5-7. Check the result on the selected CPUs and on related CPUs if the hardware groups registers. A CPU selector is a request, not a guarantee of independent hardware state.

6. Undo the change

There is no separate reset subcommand. Restore the value you recorded before step 4. For example, if the old value was 10:

$ sudo cpupower set -b 10
$ cpupower -c all info -b

Restore the same CPU scope you changed where possible. If you loaded msr only for this task, you can then unload it:

$ sudo modprobe -r msr

Do not unload the driver while another monitoring or tuning tool is using it. Reboot behaviour and persistence are outside this command's documented contract, so check the value again after reboot if it matters to your deployment.

Common traps

• Only checking core zero. cpupower info -b does not show every core by default. Use -c all for a whole-machine check.
• Confusing a hint with a frequency limit. Performance bias influences hardware trade-offs. It does not supersede operating-system P-states or idle C-states.
• Using an unsupported value. Valid values are 0 through 15. Values outside that range are not documented.
• Ignoring the wrapper warning. linux-tools-common can be present while the executable matching the running kernel is missing. Fix that packaging mismatch first.
• Assuming one CPU means one register. Related CPUs can change together because of hardware restrictions. Verify the scope you actually care about.

Done means

• Tool matches kernel. cpupower --version finds tools matching the running kernel.
• Feature supported. cpupower info -b confirms that performance bias is supported.
• Driver loaded. The msr driver is loaded when required.
• Value applied with the right scope. The chosen 0-15 value is applied with the intended CPU scope.
• Result verified. cpupower -c all info -b verifies the resulting hardware state.
• Rollback ready. The previous value is recorded, so the change can be undone.