Use cpupower Safely: Select Cores and Inspect Values

You will finish with a safe way to identify the installed cpupower, list its available command families, and target specific CPU cores without guessing what an output means. The workflow starts with read-only checks. It does not change a governor, idle state, frequency limit or other processor setting.

Allow about 15 minutes. You need a shell and the linux-tools-common package, plus the matching kernel tools if your distribution splits them by kernel version. The examples use the installed package version 6.8.0-139.139. On this machine, /usr/bin/cpupower is a wrapper and reports that it cannot find a tool for kernel 6.8.0-139. That warning is a tool-installation problem, not evidence about the processor.

1. Check which package and kernel you have

Start by recording the package version and running kernel. These commands are ordinary, read-only checks and do not need elevated privileges:

$ dpkg-query -W -f='${Package} ${Version}\n' linux-tools-common
linux-tools-common 6.8.0-139.139
$ uname -r
6.8.0-139

Your version and kernel will differ. Keep them together: the wrapper may need a kernel-specific tools package whose version matches the running kernel closely enough for your distribution to provide the executable.

Checkpoint: if the package query says that linux-tools-common is not installed, stop here and install it through your normal package-management process. If the package is installed but the kernel-specific executable is absent, do not interpret later commands as processor results.

2. Ask the installed command what it can do

The top-level command has two useful discovery forms:

$ cpupower --help
$ cpupower help

The manual defines --help and -h as general usage help. It also documents cpupower help as the overview of supported commands. The command families are separate tools with separate manuals, including information, idle, frequency and monitor commands. Read the relevant subcommand manual before using it:

$ man cpupower-info
$ man cpupower-frequency-info
$ man cpupower-frequency-set

On the machine used for this guide, both cpupower --help and cpupower help stop at the wrapper warning because the matching kernel tool is missing. The expected recovery is to provide the kernel-specific Linux tools package recommended by the warning, then repeat this step. Do not work around the warning by treating an empty result as a valid reading.

3. Confirm the package version separately

Use the short or long version option when the kernel-specific executable is available:

$ cpupower --version
$ cpupower -v

The cpupower(1) manual says that this prints the package name and version number. The Debian package query from step 1 remains useful because it tells you which package supplied the wrapper, while cpupower -v checks the executable that will actually run.

Checkpoint: use command -v cpupower if you need to confirm the path:

$ command -v cpupower
/usr/bin/cpupower

Do not confuse a successful path lookup with a usable tool. A wrapper can exist while its kernel-specific target is missing.

4. Select CPUs with the top-level option

The global CPU option is -c or --cpu, followed by a CPU list. The manual gives these forms:

$ cpupower -c 0-3 <command>
$ cpupower --cpu 0-7:2 <command>
$ cpupower -c 1,3,5-7 <command>
$ cpupower -c 0-3:2,8-15:4 <command>

They mean, respectively, CPUs 0 through 3, every second CPU from 0 through 7, CPUs 1 and 3 plus 5 through 7, and CPUs 0 and 2 plus 8 and 12. The special value all selects all cores:

$ cpupower -c all <command>

Replace <command> with a real supported subcommand, such as frequency-info, only after reading its manual. The angle brackets here mark a placeholder; do not paste them literally.

5. Check the command's default CPU scope

A common trap is assuming that every command examines the same CPUs. The top-level manual explicitly warns that -c is not supported by all commands. It also says that commands which set values typically access all cores by default, while information commands typically access only the first core by default.

That is a description of common behaviour, not a promise for every subcommand. Before comparing output, check the manual for the exact command you chose and pass -c where that command supports it:

$ man cpupower-frequency-info
$ cpupower -c 0 frequency-info

If the command does not support the global option, its own manual should say how it handles CPU selection. Do not infer that a single line of output represents every processor, and do not assume that an information command silently sampled all cores.

6. Separate inspection from changes

Information commands and setting commands have different risks. A command with info in its name is generally intended to report a value, while a command with set in its name is intended to change one. The top-level manual lists both types but leaves their detailed options to the subcommand manuals.

Before any setting command, read its manual and write down the current value with the matching information command if one exists:

$ man cpupower-frequency-set
$ man cpupower-frequency-info
$ cpupower frequency-info

Treat a setting command as service-affecting even when the change is reversible: it can alter performance, heat, battery life or latency. Use elevated privileges only when the subcommand requires them, and make that choice from its manual or a clear permission error. The top-level cpupower(1) page does not establish a universal privilege rule for every command.

Do not run a setting command from this guide as a test. If you later change a value, record the old value first and use the corresponding documented option to restore it. If the setting is managed by a service or boot configuration, undoing the immediate command may not survive the next restart.

7. Diagnose the three most likely failures

• Kernel tool missing: the wrapper prints a warning naming the running kernel and suggested packages, then exits. Install or enable the matching distribution package through your normal change process, then rerun cpupower -v.
• Unsupported CPU option: a subcommand may not implement -c. Read that subcommand's manual instead of removing the option and assuming the result is equivalent.
• Unexpected scope: an information command may inspect only the first core by default. Repeat it with a documented CPU list, or compare per-core output explicitly.

Keep the original command and exit status when troubleshooting:

$ cpupower -v
$ status=$?
$ printf 'cpupower exit status: %s\n' "$status"

The status belongs to the command immediately before the assignment. A non-zero status means the check did not complete successfully; it is not a processor measurement.