Inspect Intel RAPL Power Limits with cpupower

Use cpupower powercap-info to see whether Linux has exposed power-capping data for this machine, which driver provides it, and what limits the kernel can read. The command is an inspection tool: it does not set a limit, unload a driver, or alter firmware. Allow about five minutes, including time to check the result against the machine's hardware and kernel.

Before you start

You need a Linux system with the cpupower command from the linux-tools-common package, and a processor and driver that expose the kernel power-capping interface. The manpage describes Intel RAPL as the driver available when it was written, but support is hardware and kernel dependent.

No root shell is normally required to read the information. Start with an ordinary user account. Do not add sudo automatically: if a local policy prevents access, first confirm that the command itself works and then ask an administrator about the specific permission problem.

1. Check the installed command

Check the package version and command location before interpreting any output. The version below is an example placeholder, so replace it with the version reported on your system.

dpkg-query -W -f='${Version}\n' linux-tools-common
command -v cpupower
cpupower --version

A Debian-family system should print a package version, a path such as /usr/bin/cpupower, and the cpupower package version. The package installed for this guide is 6.8.0-139.139. The command is often tied to the running kernel's tools package, so a common failure is a wrapper that exists but cannot find matching kernel-specific tools.

2. Run the read-only inspection

Run the subcommand exactly as shown. It is the command documented by cpupower-powercap-info(1); the hyphenated name in the manpage is not a separate executable to invoke.

cpupower powercap-info

On a supported system, the output contains power-capping subsystem information exported by the kernel. Values can be platform-wide or associated with an individual core. The default view is for core zero, so do not treat it as a complete per-core inventory without checking the relevant cpupower documentation for your installed version.

3. Read the result without guessing

There are three useful outcomes.

1. Configuration is printed. The kernel has a power-capping interface and a loaded driver is exporting values. Record the names and numbers as reported. Do not infer that a value is safe to change merely because it is visible.
2. The command reports no usable support. The machine may lack compatible hardware, the power-capping driver may not be loaded, or the kernel may not expose the interface. Check the kernel log and the powercap sysfs directory before changing anything.
3. The cpupower wrapper cannot find tools for the running kernel. This is a packaging problem, not evidence that the processor lacks RAPL. Install or select the matching tools package through your normal system administration process, then rerun the version check and this command.

For a quick kernel-side check, use:

uname -r
test -d /sys/class/powercap && find /sys/class/powercap -maxdepth 2 -print | sort

A directory under /sys/class/powercap is evidence that the subsystem is present, but it is not by itself proof that every value is available or meaningful. The command's own output remains the authoritative check for what cpupower can read.

4. Investigate a missing driver

If the subsystem is absent or empty, inspect the running kernel's messages. This only reads logs and does not change the system.

dmesg --level=err,warn,info | grep -iE 'rapl|powercap'

On systems where unprivileged dmesg access is restricted, the command may fail with a permission message. Ask an administrator to run the same read-only check, or use the system's journal access policy. Do not respond by weakening kernel log permissions.

Also check that the relevant module is present before considering a load attempt:

modinfo intel_rapl 2>/dev/null | sed -n '1,12p'

The module name and availability vary by kernel build. A failed modinfo lookup does not justify installing a random module from elsewhere. Use the kernel and distribution package that match the running system.

Common traps

• Confusing inspection with configuration: powercap-info reports values. It is not a limit-setting command, but visible limits may still affect workload behaviour.
• Assuming every core is shown: the documented default is core zero, while some settings are platform-wide. Treat the display as a scoped view.
• Blaming hardware for a tools mismatch: a missing kernel-specific cpupower binary is a packaging issue. Confirm uname -r and the installed tools before diagnosing the processor.
• Using a stale sysfs snapshot: read the files and command output on the same boot. Firmware and kernel changes can alter the exposed hierarchy.