Home / Alt manpages / cpupower-monitor(1)

  • cpupower-monitor(1)
  • User command
  • linux

Measure CPU Frequency and Idle Time with cpupower monitor

You will use cpupower monitor to discover the counters available on this machine, measure a short interval, and measure a specific workload. The result is a practical view of average frequency and processor idle states without changing CPU policy or service configuration.

Allow about fifteen minutes. You need a shell and the linux-tools-common package. The installed package here is version 6.8.0-139.139. The command also needs a kernel-specific cpupower tools package to run successfully; the wrapper may report that it is missing. Most checks are unprivileged, and this guide does not change frequency governors, CPU online state or kernel settings.

1. Check the installed command

Confirm which executable your shell will use and record its package version. 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 --version
WARNING: cpupower not found for kernel 6.8.0-139

The warning above is a real prerequisite failure, not a measurement result. On a machine with the matching tools installed, cpupower --version should identify the executable rather than stopping at the kernel-tools warning. Install the package appropriate to your distribution and running kernel through your normal package-management process, then rerun this step. Do not guess a package name from another distribution.

Checkpoint

Continue only when cpupower monitor -l can execute far enough to list monitors. If it repeats the kernel-specific warning, skip interpretation of any absent output and fix the tools installation first.

2. List the monitors supported by this CPU

Run the list operation before choosing a monitor:

$ cpupower monitor -l
Monitor "Mperf" (3 states) - Might overflow after 922000000 s
   ...
Monitor "Idle_Stats" (3 states) - Might overflow after 4294967295 s
   ...

Your list will depend on the processor, kernel and available hardware interfaces. The output gives each monitor's exact name, counter count, approximate overflow time and counter scope. Names are case-sensitive in practice, so copy the name from this output when using -m. Do not assume that a monitor named after one Intel family proves that the machine has that exact CPU family. The manual says these names describe where sleep-state capabilities were introduced and can appear on related processors.

Mperf uses the aperf and mperf registers on supported x86 processors. It reports average frequency, including boost, and active versus sleeping time. Idle_Stats reads the kernel cpuidle statistics under /sys/devices/system/cpu/cpu*/cpuidle/state*/. Other systems may offer different monitors, so treat the example names as values to verify rather than defaults.

3. Measure a quiet interval

With no workload argument, the command reports periodically. Select only monitors that appeared in your own -l output and choose an interval in seconds:

$ cpupower monitor -m Mperf,Idle_Stats -i 1
Monitoring interval: 1 seconds
              Mperf                Idle_Stats
CPU    C0     Cx     AVG_MHz   C1     C2
  0   ...    ...       ...    ...    ...
  1   ...    ...       ...    ...    ...

The exact headings, CPU count and values vary. Leave the command running for a few samples, then press Ctrl-C when you have enough data. This stops the measurement process; it does not suspend the machine or alter a governor. A one-second sample is useful for a quick check, but short intervals are sensitive to scheduler activity, terminal output and background services.

Use the -c option when you specifically need the process scheduled on every core before measuring begins and ends:

$ cpupower monitor -c -m Idle_Stats -i 2
Monitoring interval: 2 seconds
              Idle_Stats
CPU    C1     C2     C3
  0   ...    ...    ...

This option can help Idle_Stats wake processors and let the kernel re-account cpuidle timings before reading them. It is not a way to make a CPU busy, and it may disturb the workload you are trying to observe. Use it only when that measurement detail matters.

4. Measure a bounded command

To measure one workload, put the executable and its arguments after the monitor options:

$ cpupower monitor -m Idle_Stats,Mperf /usr/bin/sleep 3
              Idle_Stats                Mperf
CPU    C1     C2     C3       C0     Cx     AVG_MHz
  0   ...    ...    ...       ...    ...       ...
  1   ...    ...    ...       ...    ...       ...

The program is forked, and counters gathered from its start are displayed when it exits. Substitute a harmless command that represents the question you are asking, such as a test binary or a bounded file operation. Do not use a command that can run indefinitely unless you already have a safe termination plan. The command's output may be mixed with the measurement output, so choose a quiet workload when you need easy-to-parse results.

There is a subtle shell trap in the manual. This does not measure a useful busy CPU:

$ cpupower monitor cat /dev/zero >/dev/null

The redirection hides the measured command's output, and the example can keep running until you interrupt it. If you need a sustained test, place a bounded workload in a small, reviewed script and invoke that script. Keep the test duration finite, and press Ctrl-C to stop it if it does not terminate as expected.

5. Interpret the counters without overclaiming

An average frequency from Mperf includes boost frequencies, so it is not necessarily the advertised base frequency. Its active and sleep counters are based on a timer that stops ticking in idle states on recent supported hardware. Results are still tied to the processor and kernel support available on the host.

Idle_Stats can be less precise at the measurement boundaries. The kernel updates a state counter when an idle state is entered or left. If a core remains in a state for the whole interval, its exported value may not be updated in time, and a displayed zero percent can represent a longer residency. Treat a single short sample as evidence about that sample, not as a complete power diagnosis.

For a repeatable comparison, keep the interval, selected monitors, workload, CPU affinity and background activity consistent. Record the command and package/kernel versions beside the result. Do not compare a package or kernel-specific monitor result with another host as though the counter definitions were identical.

6. Troubleshoot without changing system state

If -l prints the kernel-tools warning, check the running kernel and installed packages:

$ uname -r
6.8.0-139-generic
$ dpkg-query -W -f='${Package} ${Version}\n' 'linux-tools*' 2>/dev/null

Use the missing kernel release to choose the matching tools package through your normal distribution repository. Elevated privileges are not a general fix for a missing executable or unsupported monitor. If a selected monitor fails because its hardware interface is unavailable, remove it from -m and choose one that -l actually lists.

The manual names /dev/cpu/*/msr and the cpuidle sysfs paths as data sources. Their presence does not guarantee that every monitor works: the CPU, kernel driver and permissions must also support the relevant counter. Inspecting those paths is read-only; do not create device nodes, load arbitrary modules or alter boot parameters just to force a result.

Done means

  • cpupower monitor -l runs without the kernel-specific tools warning.
  • You selected monitor names from the installed machine's own list.
  • You measured a fixed interval or a bounded command and saved the command used.
  • You know whether the result came from Mperf, Idle_Stats or another monitor.
  • You treated short samples and idle-boundary readings as estimates, not complete power diagnoses.
  • No governor, service, CPU state or persistent configuration was changed.