Safely Change CPU Frequency Policies with cpupower

This guide changes a Linux CPU frequency policy in a controlled way, verifies the result, and restores the previous values afterwards. These examples use the locally installed linux-tools-common package, version 6.8.0-139.139. Allow about fifteen minutes, including time to record the current policy before touching it.

This command changes live kernel settings. It does not permanently edit a configuration file, but it can still affect performance, heat, battery life and a running workload. Use a maintenance window on a busy machine, hold onto the original values, and never guess a frequency or governor name.

1. Confirm the command and its scope

Check the installed wrapper and package before doing anything that changes state. These are ordinary, read-only commands:

$ command -v cpupower
/usr/bin/cpupower
$ dpkg-query -W -f='${Package} ${Version}\n' linux-tools-common
linux-tools-common 6.8.0-139.139
$ cpupower frequency-set --help

The command takes the form cpupower [ -c CPU_LIST ] frequency-set OPTIONS. The set operation applies to all cores by default; the top-level -c or --cpu option narrows it to a CPU list, such as 0 or 0-3. Do not reach for --related as a substitute for choosing a CPU list, since it actually widens the operation to every hardware-related CPU.

Checkpoint: if the help command reports a missing kernel-specific cpupower binary, stop here and install the matching tools through your normal package process. A wrapper warning is no evidence that a frequency change ever succeeded.

2. Record the current policy

Read the current policy before you change anything. The companion information command exists for exactly this inspection:

$ cpupower frequency-info --policy
$ cpupower frequency-info --driver
$ cpupower frequency-info --governors

The output is entirely host-specific. Record the current minimum, maximum and governor, together with the CPU scope you inspected. By default the information command reports core zero, while frequency-set changes every core unless you select a CPU list: that gap is an easy way to end up validating the wrong thing.

Some drivers expose a policy shared across several CPUs. Use cpupower frequency-info --related-cpus to see which CPUs share a hardware frequency, then decide whether your planned scope actually matches that policy. If an information command fails outright, resolve that first rather than pressing on with sudo.

3. Choose a valid governor

Use one of the names --governors prints. A governor is a policy choice, not a fixed clock speed. For example, this asks the kernel to use a governor called GOVERNOR_NAME across the default all-core scope:

$ sudo cpupower frequency-set --governor GOVERNOR_NAME

Replace GOVERNOR_NAME with an exact name pulled from your own output. sudo appears here because writing cpufreq policy commonly needs elevated access; drop it if your system already grants you the required permission. A successful command is not proof every CPU now shares the same policy, so re-run the information command with the relevant CPU selection and check the result.

Checkpoint: if the requested governor is unavailable, the command should fail outright rather than inventing one. Go back to step 2 and use a name the active driver actually supports.

4. Set safe minimum and maximum limits

--min and --max set the lowest and highest frequency the governor may pick. Frequencies default to kHz, but the command also accepts a suffix with no space, including MHz, GHz and Hz:

$ sudo cpupower frequency-set --min MIN_FREQUENCY --max MAX_FREQUENCY

Replace both placeholders with values your driver actually permits, such as 800MHz and 2.40GHz, only after checking the machine's own limits. Keep the minimum no greater than the maximum, and never copy those example values blindly: hardware, firmware and the active cpufreq driver all decide the valid range.

To change only selected CPUs, put -c ahead of the command name:

$ sudo cpupower -c 0-3 frequency-set --min MIN_FREQUENCY --max MAX_FREQUENCY

Verify the limits with cpupower -c 0-3 frequency-info --policy. If your driver coordinates related CPUs, the resulting policy may end up covering more hardware than the list alone suggests.

5. Set one specific frequency only when userspace is available

--freq requests one exact frequency. It needs the userspace governor loaded and available, and it cannot be combined with --min, --max, --governor or --related:

$ sudo cpupower frequency-set --freq FREQUENCY

Use this only once frequency-info --governors shows the required userspace support, and the requested frequency is genuinely valid for the policy. A fixed request removes the flexibility that would otherwise let a governor respond to load, making it a poor first test on a production host.

6. Verify or undo the change

Run the same inspection command against the same CPU scope you used in step 2:

$ cpupower -c CPU_LIST frequency-info --policy
$ cpupower -c CPU_LIST frequency-info --governors

Compare the reported policy against your recorded values. A command that returns without an obvious error is not enough on its own: the driver may round a requested frequency, or apply a policy to related CPUs you did not list.

To undo the change, run frequency-set again with the exact original governor and limits you recorded, using the same CPU scope if you changed one. There is no generic reset value built into this command, and rebooting is never a substitute for having actually recorded the previous settings.

Done means