Read Linux CPUFreq State with cpupower frequency-info

cpupower frequency-info gives you a read-only look at the CPU frequency driver, policy, limits, governors and available statistics on a Linux host. These examples use that subcommand from the locally installed linux-tools-common package, version 6.8.0-139.139.

Allow about ten minutes. You need a shell and the cpupower command. Most checks here are ordinary user commands; hardware frequency sampling with --hwfreq is the exception, since the installed manpage says it is available only to root. This guide only reads state: it does not change a governor, frequency limit, driver or service.

1. Check the installed command

Start by confirming which executable will run and which package supplied it:

$ 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 --version

On this host, the wrapper also prints a warning that matching tools for kernel 6.8.0-139 are missing, leaving it with no usable frequency backend. Seeing that warning means treating later empty or warning-only output as a tooling problem, not as proof CPUFreq is absent. Install the matching distribution package through your normal system administration process, then rerun this step; package installation itself sits deliberately outside this read-only guide.

Checkpoint: record the path and package version before you start comparing results between machines.

2. Run the default overview

The simplest command is just:

$ cpupower frequency-info

The subcommand is commonly called frequency-info, and its installed manual page is named cpupower-frequency-info(1). The default output covers core zero only, an easy trap on a machine with several CPUs or where a policy groups CPUs together.

That overview is really a bundle of separate questions. The output-specific options pick one at a time: --driver reports the kernel driver, --policy reports the current CPUFreq policy, --governors lists available governors, and --hwlimits reports the minimum and maximum allowed frequency.

Do not combine those output selectors in one invocation. The manpage says only one of --proc, --debug, --affected-cpus, --governors, --policy, --driver, --hwlimits, --hwfreq, --freq or --latency may be given at a time.

3. Inspect one CPUFreq property at a time

Use the long option names in scripts and notes so the question being asked is obvious:

$ cpupower frequency-info --driver
$ cpupower frequency-info --policy
$ cpupower frequency-info --governors
$ cpupower frequency-info --hwlimits
$ cpupower frequency-info --stats
$ cpupower frequency-info --latency

Some properties may simply be unavailable: a system can lack a matching driver interface, a governor list, or CPUFreq statistics. The --stats result depends on statistics support exposed by the kernel itself. An unavailable result is still useful evidence about this host, so do not fill it in from another machine or infer a governor from a distribution default.

The installed manpage describes --freq as the frequency reported by the CPUFreq core:

$ cpupower frequency-info --freq

That is a different question from --hwfreq, which reads the frequency straight from hardware and requires root according to the manpage:

$ sudo cpupower frequency-info --hwfreq

Reach for sudo only when the hardware-reading check genuinely needs it. A failed command is never a reason to change permissions on files under /sys, and nothing here needs to write to them anyway.

4. Select the CPUs you actually mean

Pass a CPU list to the top-level cpupower command, ahead of frequency-info:

$ cpupower --cpu 0 frequency-info --driver
$ cpupower --cpu 0-3 frequency-info --policy
$ cpupower --cpu 1,3,5-7 frequency-info --governors

The list syntax supports ranges, comma-separated CPU numbers and a stride, so 0-7:2 selects CPUs 0, 2, 4 and 6. Use a list that actually exists on the host, checking first if you are not sure:

$ nproc
$ lscpu -e=CPU,ONLINE

The command defaults to core zero, not every core. CPUs that share a hardware frequency or get coordinated by software also are not necessarily independent observations, so compare --related-cpus and --affected-cpus when that distinction actually matters:

$ cpupower --cpu 0 frequency-info --related-cpus
$ cpupower --cpu 0 frequency-info --affected-cpus

The local manual page presents both of those queries under -a, so stick to the long names to avoid ambiguity.

5. Make frequency output easier to compare

--human changes the presentation for frequency, hardware-frequency, statistics and latency queries. Add --no-rounding whenever exact values matter:

$ cpupower frequency-info --freq --human
$ cpupower frequency-info --freq --no-rounding
$ cpupower frequency-info --stats --human --no-rounding

These stay entirely read-only. Human-readable output suits a report, while unrounded output suits comparing logs or checking a threshold. Keep the command line together with whatever output you captured, so another reader knows which representation they are looking at.

For a diagnostic bundle, run the individual queries separately rather than trying to combine them. A small shell loop is safe here because every command only reads CPUFreq information:

for query in --driver --policy --governors --hwlimits --freq --stats; do
    printf '\n== %s ==\n' "$query"
    cpupower frequency-info "$query"
done

If the machine is missing its kernel-specific cpupower tools, this loop just repeats the same warning six times. Fix the package mismatch first, rather than reading those repeats as six independent CPU failures.

6. Handle unavailable or misleading results

CPUFreq information comes from kernel interfaces. Current Linux documentation describes policy objects under /sys/devices/system/cpu/cpufreq/, with links from each CPU's own directory into the policy it belongs to. So the command may well report a policy shared across multiple CPUs rather than a private setting for one logical CPU.

Use these read-only checks when a result is empty or looks wrong:

$ test -d /sys/devices/system/cpu/cpufreq && echo 'CPUFreq policy directory exists'
$ find /sys/devices/system/cpu -maxdepth 3 -path '*/cpufreq' -type d -print 2>/dev/null

An absent directory, an offline CPU, a driver limitation and a missing userspace tool are four different conditions. Record the kernel release, package version and exact command before escalating, and never switch governors or write a new frequency limit as a diagnostic shortcut: those actions change system behaviour and deserve their own maintenance decision, monitoring and rollback plan.

The deprecated --proc option prints information in the style of the old /proc/cpufreq interfaces. Use it only when a legacy report genuinely requires that format. It cannot be combined with the CPU selection option, and it will not conjure a modern /proc/cpufreq interface into existence either.