Safely tune CPU idle states with cpupower idle-set

You will disable or re-enable selected CPU idle states, or apply a latency threshold, then verify the kernel's policy without guessing from a benchmark. Allow about 15 minutes for a reversible test. The examples change live kernel state, so use them on a machine where a short power or latency change is acceptable.

1. Check the installed tool and kernel policy

This guide follows the cpupower-idle-set(1) shipped by the installed linux-tools-common package, version 6.8.0-139.139. The package also installs a wrapper at /usr/bin/cpupower. On this host, that wrapper cannot find a kernel-specific binary for kernel 6.8.0-139, so it prints a warning and exits. Your host needs a matching Linux tools package before the subcommand can run.

$ dpkg-query -W -f='${Package} ${Version}\n' linux-tools-common
linux-tools-common 6.8.0-139.139
$ command -v cpupower
/usr/bin/cpupower
$ cpupower idle-info
WARNING: cpupower not found for kernel 6.8.0-139

The version string is distribution packaging information, not a promise that every kernel has the same idle-state driver. If your command prints the same warning, stop here and install the matching tools through your normal package-management process. Do not work around it by writing directly to sysfs unless you have a separate reason to manage the kernel interface yourself.

2. Record the current states before changing them

Run this inspection as an ordinary user. It reads the kernel's per-CPU idle-state files and shows the state number, name, exit latency and current disable flag. The state number is the value passed to --disable or --enable; it is not necessarily the same as the depth of a platform-specific C-state name.

$ for state in /sys/devices/system/cpu/cpu0/cpuidle/state*; do
    printf '%s ' "${state##*/}"
    printf 'name='; cat "$state/name"
    printf 'latency='; cat "$state/latency"
    printf 'disable='; cat "$state/disable"
  done
state0 name=POLL latency=0 disable=0
state1 name=C1 latency=2 disable=0
state2 name=C1E latency=10 disable=0
state3 name=C3 latency=70 disable=0
state4 name=C6 latency=85 disable=0
state5 name=C7s latency=124 disable=0
state6 name=C8 latency=200 disable=0

Output varies with the CPU, firmware and selected idle driver. Check more than cpu0 if your workload uses a restricted CPU set. By default, cpupower idle-set applies the change to all CPU cores. The parent cpupower command has a CPU-selection option, so use its installed manual page when you need to target a particular core list.

Checkpoint: save the current disable values somewhere you can read while recovering. A value of 0 means the state is enabled in the sysfs policy; a value of 1 means it is disabled.

3. Disable one state for a controlled test

Disabling an idle state requires elevated privileges and takes effect immediately. It can alter power use, wake latency and thermal behaviour, and it may affect every core. Choose a state number from your inspection rather than copying 6 blindly.

$ sudo cpupower idle-set --disable STATE_NO

Replace STATE_NO with a real number, for example 4 after confirming that state4 exists:

$ sudo cpupower idle-set --disable 4
$ cat /sys/devices/system/cpu/cpu0/cpuidle/state4/disable
1

The command normally produces no success message. The readback is the useful verification. A non-zero exit status or a permission error means the requested policy was not established. Check the matching tools package, the state number and the kernel's cpuidle support before retrying.

4. Restore the state after the test

Re-enable the exact state with --enable. This is the undo operation for the previous example:

$ sudo cpupower idle-set --enable 4
$ cat /sys/devices/system/cpu/cpu0/cpuidle/state4/disable
0

Keep the original values until you have checked every CPU that mattered. A state may remain disabled on another core if your command was run with a CPU selection, or a governor may still make deeper states unavailable in practice. Re-enabling a state does not force the kernel to choose it on the next idle period.

5. Apply a latency threshold carefully

--disable-by-latency LATENCY changes the whole set of idle states. It disables states with latency equal to or above the supplied value and enables states below it. This is convenient for a broad policy, but it can undo earlier per-state choices, so record the state before running it.

$ sudo cpupower idle-set --disable-by-latency LATENCY_US

For example, with the sample latencies above, a threshold of 100 disables states at 100 microseconds or more, including C7s at 124 and C8 at 200, while leaving C6 at 85 enabled:

$ sudo cpupower idle-set --disable-by-latency 100
$ for state in /sys/devices/system/cpu/cpu0/cpuidle/state*; do
    printf '%s latency=' "${state##*/}"; cat "$state/latency"
    printf 'disable='; cat "$state/disable"
  done
state4 latency=85 disable=0
state5 latency=124 disable=1
state6 latency=200 disable=1

Use the actual latency files on your machine. The argument is a latency value, not a state number. To undo a threshold policy, use --enable-all, which enables every idle state that is not already enabled:

$ sudo cpupower idle-set --enable-all
$ cat /sys/devices/system/cpu/cpu0/cpuidle/state5/disable
0

6. Account for the cpuidle governor

The kernel governor still decides which enabled state to enter. The installed manual specifically warns that ladder and menu can impose additional policy. With ladder, disabling a light state can also prevent deeper states from being used, while enabling a deep state may have no practical effect while a lighter state remains disabled.

$ cat /sys/devices/system/cpu/cpuidle/current_governor
menu
$ cat /sys/devices/system/cpu/cpuidle/current_driver
intel_idle

This is why a successful command and a changed disable flag are not the same as a guaranteed residency change. For a meaningful test, measure the workload and inspect state usage with cpupower idle-info once a matching binary is installed. The lightest state can still be entered in some circumstances even after it is marked disabled, and its usage count may reflect that.

7. Avoid making the change persistent by accident

cpupower idle-set changes the live kernel policy. The manpage describes the relevant sysfs paths under /sys/devices/system/cpu, but it does not provide a persistent configuration file or a boot-time guarantee. A reboot normally gives you a fresh policy, subject to the kernel and firmware defaults. Do not put a command into a service, udev rule or boot script until you have tested the effect and written down a rollback command.

Do not disable idle states on a production host during an incident merely to make a latency graph look better. First capture the current values, limit the CPU scope if appropriate, and arrange a maintenance window. If the change causes unwanted heat, power use or scheduling behaviour, run sudo cpupower idle-set --enable-all, verify the flags, and then remove any wrapper or service configuration you added.