# PowerTOP: diagnosing where a Linux machine's power actually goes, and tuning it > PowerTOP is a C++ diagnostic for Linux power consumption and power management, with an interactive mode for experimenting with settings, three report formats, and a non-interactive auto-tune mode. The 2.16 series moved the build to Meson and C++20, and v2.16.1 shipped on 2026-10-07. **fenrus75/powertop** — The Linux PowerTOP tool -- please post patches to the mailing list instead of using github pull requests - Repository: https://github.com/fenrus75/powertop - Website: http://www.01.org/powertop - Stars: 1,346 · Forks: 144 - Language: C++ - License: GPL-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/fenrus75-powertop ## A diagnostic that also hands you the switch PowerTOP is a Linux tool used to diagnose issues with power consumption and power management. That is the first job, and it is the one the name suggests. The second job is less common and more useful in practice. In addition to being a diagnostic tool, PowerTOP has an interactive mode you can use to experiment with various power management settings, for cases where the Linux distribution has not enabled those settings. The mode resembles `top`, and you move between the Overview, Idle stats, Frequency stats, Device stats, Tunables, and WakeUp tabs with Tab and Shift-Tab. That second capability is what separates it from a passive profiler. A tool that only measures tells you that a device is burning power. A tool that also lets you toggle the setting and watch the number move tells you whether the setting is the cause. The Tunables tab is where the diagnosis becomes an experiment. The tool must be run as root, which is a consequence of what it does rather than an arbitrary requirement: it reads kernel trace data and inspects device state. That requirement is also the reason to think carefully about where the reports end up, a point the documentation raises in a way that is easy to miss. The project is under active development, with v2.16 released on 2026-08-10 and v2.16.1 on 2026-10-07, and the last push to the repository was on the same day as the maintenance release. ## Building needs Meson and four required libraries PowerTOP is written in C++ and targets Linux, and it now uses the Meson build system. The required libraries are ncurses for the interface, libnl-3 for netlink, libtracefs and libtraceevent for the trace data it consumes, with libpci optional and only needed if the system has PCI devices, and gettext optional for translated messages. The Ubuntu example installation is a single apt invocation: ```bash sudo apt install meson ninja-build libpci-dev libnl-3-dev libnl-genl-3-dev \ libncursesw5-dev libtracefs-dev libtraceevent-dev gettext pkg-config ``` The two-step build then follows the standard Meson pattern: ```bash meson setup build ninja -C build ``` The test suite gets its own build directory, because the tests are compiled in only when you ask for them: ```bash meson setup -Denable-tests=true build_test ninja -C build_test test ``` Two separate directories rather than one means your working build is not carrying the test configuration, and the `-Denable-tests=true` option is the meson-specific way of saying so. The move to Meson is itself a change worth noting, because the release notes for v2.16 list the build system change and C++20 among the highlights, and the v2.16.1 maintenance release lists the removal of legacy autoconf. A project that has carried an autoconf build for years and then dropped it has usually done so because the remaining build logic now lives in a system that handles cross-compilation and dependency discovery better. The repository layout reflects a mature C++ project with packaging attached: `src/`, `tests/`, `po/` for translations, `m4/` for the remaining macro machinery, `scripts/`, `patches/`, `doc/` with the release notes, a `meson.build` and `meson_options.txt` at the root, a `.clang-format` for the C++ style, and a `powertop.service` unit file. ## Reports come in three shapes and share one measurement cycle PowerTOP supports three report formats, and the structure is the same for all of them. Every report mode takes one measurement cycle, controlled by `--time`, and then writes the report and exits. That is a clean separation between the interactive tool and the batch tool, and it means a report is always a bounded, reproducible artefact rather than whatever the screen happened to show. The HTML format is the rich report suitable for sharing, and the Markdown format is a plain-text report suitable for viewing in any Markdown renderer. The CSV format is the machine-readable one: ```bash powertop --html # writes powertop.html powertop --markdown # writes powertop.md powertop --csv # writes powertop.csv ``` Each accepts a filename if you want to control the output path, for example `powertop --html=myreport.html`. The measurement controls are what make the reports useful for comparison. `--time=N` sets how many seconds each iteration collects data for, with a default of 20, and `--iteration=N` runs N measurement iterations, default 1. Multiple iterations exist to average, so a single noisy run does not become your baseline: ```bash powertop --html --iteration=5 --time=20 # 5 iterations × 20 s each ``` You can also run a workload while measuring, which turns the report into a measurement of a specific activity rather than of whatever the machine happened to be doing: ```bash powertop --html --workload=/path/to/script.sh ``` And there is a `--once` option that runs one measurement cycle and exits without going interactive, which is what you want in a script where the interactive mode would hang. The security note deserves its own attention. Because PowerTOP is intended for privileged root use, reports, especially those generated with `--debug`, will contain verbose system information, and PowerTOP does not sanitize or anonymize its reports. A report attached to a public bug tracker is a disclosure of your machine's internals. ## Auto-tune applies everything, so dump it before you run it The automated tuning mode is the feature that gets PowerTOP into build scripts and configuration management, and it is also the feature most likely to cause a surprise. PowerTOP can apply all recommended power-saving settings in one shot without entering interactive mode: ```bash sudo powertop --auto-tune ``` The safer path is the dump variant, which previews what changes would be made without actually applying them: ```bash sudo powertop --auto-tune-dump ``` The output of `--auto-tune-dump` is a list of shell commands, and the documented pattern is to redirect it to a script, review it, and then run it: ```bash sudo powertop --auto-tune-dump > tune.sh # review tune.sh, then: sudo bash tune.sh ``` That is a good pattern for two reasons. It puts the changes in a file you can read, diff, and commit, which means the tuning becomes a reviewable artefact rather than an action with no trace. And it lets you apply selectively or at boot time, which the documentation mentions as the reason to redirect the output in the first place. The `sudo` on every one of these commands is not incidental. The tool must run as root, and the generated script inherits that. The v2.16 release notes also list the `--auto-tune-dump` option among the additions in the v2.16-rc2 milestone alongside a vertical scrollbar, terminal resize support, the Meson build, and C++20. The terminal resize support and the vi-style navigation keys in the following maintenance release are the kind of detail that only matters once you actually use the interactive mode on a terminal that resizes. ## Calibration is what makes the power numbers mean anything PowerTOP, when running on battery, tracks power consumption and activity to build up per-device power estimates, and the documentation is direct that you can improve the accuracy of these estimates by running a calibration cycle at least once: ```bash powertop --calibrate ``` Calibration cycles through various display brightness levels, including off, USB device activities, and other workloads. The instruction is to run it on battery with no other active workload for best results. This is the part of the tool that is easy to skip and wrong to skip. The per-device power estimates are what the tool uses to attribute consumption to a device, and an uncalibrated estimate is a guess with a number attached. Calibration gives the tool a baseline for each device's behaviour under known conditions, so the later attribution rests on measurement rather than on a default cost model. The requirement to run it on battery with nothing else happening is not fussiness either, because the whole point is to observe what the device consumes when the machine is otherwise idle. The mention of display brightness levels in the calibration cycle also explains why a laptop and a server behave differently here. A machine with a backlit display has a power consumer that varies with user settings, and the calibration has to visit those levels to establish the relationship. On a headless server, that part of the cycle has nothing to sweep. The v2.16 release notes also mention Wayland-safe calibration among the highlights for the series, alongside the AMD GPU tunable and the CPU stats TUI redesign, which tells you the calibration path has been adjusted for the display server situation that has changed in recent Linux desktops. ## What the kernel has to provide, and what a report exposes PowerTOP needs a set of kernel configuration options enabled to function properly. The documentation notes that modern distribution kernels typically have all of these enabled already, and that the check matters if you are running a minimal or custom kernel: ``` CONFIG_NO_HZ CONFIG_HIGH_RES_TIMERS CONFIG_CPU_FREQ_GOV_ONDEMAND CONFIG_PERF_EVENTS CONFIG_TRACEPOINTS CONFIG_TRACING CONFIG_DEBUG_FS CONFIG_POWERCAP CONFIG_INTEL_RAPL # Intel systems only ``` The list explains what the tool depends on. The tracing options and CONFIG_DEBUG_FS are how it gets per-device activity, CONFIG_NO_HZ and CONFIG_HIGH_RES_TIMERS are how it measures idle time accurately rather than approximately, CONFIG_PERF_EVENTS is how it reads CPU frequency and residency counters, and CONFIG_POWERCAP is how it knows about the power management framework. CONFIG_INTEL_RAPL is marked Intel systems only, and it is the hardware energy counter that makes real power figures possible on those machines rather than an estimate. That last point is the practical boundary of the tool's power numbers. On a machine without a RAPL counter, the power figures are modelled. On one with it, they are measured. The report looks the same either way, which is why reading the kernel support is part of interpreting the output. Two smaller capabilities are worth knowing. The tool supports the Extech Power Analyzer and Datalogger, model 380803, over a serial connection, with the device node passed on the command line: ```bash powertop --extech=/dev/ttyUSB0 ``` where ttyUSB0 is the device node of the serial-to-USB adapter. That is external measurement hardware plugged into the machine, which is the way to check the tool's own estimates against an instrument. And for a bug report, the documented procedure is to generate a debug HTML report and file the issue: ```bash powertop --debug --html=bugreport.html ``` The bug report then goes to the GitHub issues page, and the debug flag is exactly what makes the report sensitive, so that is a report you share with the project rather than one you post publicly. ## Conclusion PowerTOP fits a laptop or server administrator who needs to know which subsystem is wasting power, who needs a report they can attach to a bug, and who wants to apply the recommended tunables in a script rather than by hand. It is the wrong tool on a system where the kernel lacks the tracepoints it depends on, and it is a poor choice for sharing reports casually because the documentation states plainly that reports are not sanitized. Verify three things first: that your kernel has the listed configuration options enabled, that you are willing to run it as root, since that is required, and that you read the output of `powertop --auto-tune-dump` before running the generated script, because the tool will happily apply every recommended setting at once. ## FAQ ### How do I build PowerTOP from source? Install the build dependencies, which on Ubuntu are meson, ninja-build, libpci-dev, libnl-3-dev, libnl-genl-3-dev, libncursesw5-dev, libtracefs-dev, libtraceevent-dev, gettext, and pkg-config. Then run `meson setup build` followed by `ninja -C build`, and for the test suite use `meson setup -Denable-tests=true build_test` and `ninja -C build_test test`. ### How do I apply PowerTOP's recommended power settings automatically? Run `sudo powertop --auto-tune` to apply all recommended settings at once, or `sudo powertop --auto-tune-dump` to preview them as a list of shell commands. The documented pattern is to redirect the dump to a script, review it, and then run it with `sudo bash tune.sh`. ### Why do my PowerTOP power estimates look wrong? PowerTOP builds up per-device power estimates over time when running on battery, and the documentation says to improve their accuracy by running a calibration cycle at least once with `powertop --calibrate`. Calibration cycles through display brightness levels including off, USB device activities, and other workloads, and is best run on battery with no other active workload. ### Is it safe to share a PowerTOP report? Be careful. The documentation states that because PowerTOP is intended for privileged root use, reports, especially those generated with `--debug`, will contain verbose system information, and that PowerTOP does not sanitize or anonymize its reports. ### Which kernel options does PowerTOP need? The listed options are CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS, CONFIG_CPU_FREQ_GOV_ONDEMAND, CONFIG_PERF_EVENTS, CONFIG_TRACEPOINTS, CONFIG_TRACING, CONFIG_DEBUG_FS, CONFIG_POWERCAP, and CONFIG_INTEL_RAPL on Intel systems. Modern distribution kernels typically have all of them enabled already, so the check matters mainly for minimal or custom kernels. ## Sources - [fenrus75/powertop on GitHub](https://github.com/fenrus75/powertop) - [License: GPL-2.0](https://github.com/fenrus75/powertop/blob/master/LICENSE) - [Project website](http://www.01.org/powertop) - [README](https://github.com/fenrus75/powertop/blob/master/README.md) - [Releases](https://github.com/fenrus75/powertop/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fenrus75-powertop