Select CPU Cores and Inspect Values Safely with cpupower

cpupower has a lot of subcommands, so start here: identify the installed tool and list what it can do. Then learn to target specific cores without guessing at what the output means. The workflow sticks to read-only checks throughout. It never changes 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 out by kernel version. These examples use the installed package version 6.8.0-139.139. On this machine, /usr/bin/cpupower is a wrapper that reports it cannot find a tool for kernel 6.8.0-139. That warning is a tool-installation problem, not evidence about the processor itself.

1. Check which package and kernel you have

Start by recording the package version and the running kernel. Both are ordinary, read-only checks that need no 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 from these. Keep them together: the wrapper may need a kernel-specific tools package whose version matches the running kernel closely enough for your distribution to actually provide the executable.

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

2. Ask the installed command what it can do

The top-level command offers two useful discovery forms:

$ cpupower --help
$ cpupower help

The manual defines --help and -h as general usage help, and separately documents cpupower help as the overview of supported commands. The command families themselves are separate tools with separate manuals, covering information, idle, frequency and monitor commands. Read the relevant subcommand manual before you use 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 dead at the wrapper warning because the matching kernel tool is missing. The fix is to install the kernel-specific Linux tools package the warning recommends, then repeat this step. Do not treat an empty result as a valid reading just to work around the warning.

3. Confirm the package version separately

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

$ cpupower --version
$ cpupower -v

The cpupower(1) manual says this prints the package name and version number. The Debian package query from step 1 still matters 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 mistake a successful path lookup for a usable tool. A wrapper can exist perfectly well 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>

In order, those mean 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 every core:

$ cpupower -c all <command>

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

5. Check the command's default CPU scope

A common trap is assuming every command examines the same CPUs. The top-level manual explicitly warns that -c is not supported by every command, and that commands which set values typically touch all cores by default, while information commands typically look at just the first core by default.

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

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

If a command does not support the global option, its own manual should explain how it handles CPU selection instead. Never assume a single line of output speaks for every processor, or that an information command silently sampled all cores.

6. Separate inspection from changes

Information commands and setting commands carry very different risks. A command with info in its name generally reports a value; one with set in its name generally changes one. The top-level manual lists both types but leaves the detailed options to each subcommand's own manual.

Before any setting command, read its manual and write down the current value using 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 it is reversible: it can shift performance, heat, battery life or latency. Use elevated privileges only when the subcommand actually requires them, and let its manual or a clear permission error make that decision for you. The top-level cpupower(1) page sets no universal privilege rule that covers every command.

Never run a setting command from this guide just as a test. If you do change a value later, record the old one 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 simply not implement -c. Read that subcommand's manual instead of dropping the option and assuming the result means the same thing.
• Unexpected scope: an information command may look at 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 handy while troubleshooting:

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

That status belongs to the command run immediately before the assignment. A non-zero status means the check itself did not complete, not that you have measured anything about the processor.