Read Linux CPUFreq State with cpupower frequency-info

You will finish with a read-only check of the CPU frequency driver, policy, limits, governors and available statistics on a Linux host. The examples use cpupower frequency-info 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 are ordinary user commands. Hardware frequency sampling with --hwfreq is the exception described below: the installed manpage says it is available only to root. This guide reads state only. 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 not installed. It then has no usable frequency backend. If you see that warning, treat later empty or warning-only output as a tooling problem, not as proof that CPUFreq is absent. Install the matching distribution package through your normal system administration process, then rerun this step. Package installation is deliberately outside this read-only guide.

Checkpoint: the path and package version should be recorded before comparing results between machines.

2. Run the default overview

The simplest command is:

$ cpupower frequency-info

The subcommand is commonly called frequency-info; its installed manual page is named cpupower-frequency-info(1). The default output concerns core zero only. That is an easy trap when a machine has several CPUs or when a policy groups CPUs together.

The overview is a collection of separate questions. The output-specific options select one question 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 that only one of --proc, --debug, --affected-cpus, --governors, --policy, --driver, --hwlimits, --hwfreq, --freq or --latency may be specified at a time.

3. Inspect one CPUFreq property at a time

Use the long options in scripts and notes because they make the question 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 be unavailable. A system can lack a matching driver interface, a governor list, or CPUFreq statistics. The --stats result depends on the statistics support exposed by the kernel. An unavailable result is useful evidence about this host; 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

This is not the same question as --hwfreq. The latter reads the frequency from hardware and requires root according to the manpage:

$ sudo cpupower frequency-info --hwfreq

Use sudo only when the hardware-reading check needs it. A failed command does not justify changing permissions on files under /sys, and no command here needs a write to those files.

4. Select the CPUs you actually mean

Pass a CPU list to the top-level cpupower command, before 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. For example, 0-7:2 selects CPUs 0, 2, 4 and 6. Use a list that exists on the host, and check it first if you are unsure:

$ nproc
$ lscpu -e=CPU,ONLINE

The command's default is core zero, not all cores. Also, CPUs that share a hardware frequency or are coordinated by software are not necessarily independent observations. Compare --related-cpus and --affected-cpus when that distinction 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 use the long names to avoid ambiguity.

5. Make frequency output easier to compare

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

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

These are still read-only views. Human-readable output is convenient for a report, while unrounded output is better for comparing logs or checking a threshold. Keep the command line with the captured output so another reader knows which representation they are seeing.

For a diagnostic bundle, run the individual queries rather than trying to combine them. A small shell loop is safe 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 will repeat the same warning. Fix the package mismatch first; do not interpret repeated warnings as six independent CPU failures.

6. Handle unavailable or misleading results

CPUFreq information comes from kernel interfaces. The current Linux documentation describes policy objects under /sys/devices/system/cpu/cpufreq/, with links from CPU directories for the CPUs belonging to each policy. The command may therefore report a policy shared by multiple CPUs rather than a private setting for one logical CPU.

Use these read-only checks when the result is empty or unexpected:

$ 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 different conditions. Record the kernel release, package version and exact command before escalating. Do not switch governors or write a new frequency limit as a diagnostic shortcut. Those actions change system behaviour and need a separate maintenance decision, monitoring and rollback plan.

The deprecated --proc option prints information in the style of old /proc/cpufreq interfaces. Use it only when a legacy report explicitly requires that format. It cannot be combined with the CPU selection option, and it does not make a modern /proc/cpufreq interface appear.