Independent tech desk · no vendor sponsorshipPractical answers, not release notes
Numix Desk for the Linux desktop, open source and the machines we use every day

HardwareMistakes

Laptop Battery Life on Linux: The Mistakes That Cost the Most Hours

A measurement-first order of work instead of a list of tweaks copied from a wiki

Acer AC10D31 Li-ion battery pack-3588
Photo: Raimond Spekking / Wikimedia Commons · CC BY-SA 4.0

Linux Laptop Battery Drain Fix: Where to Focus and Why

When your Linux laptop loses battery hours that it runs on Windows, generic power tools like TLP or power management daemons are not your guaranteed answer. To shrink the real drains in a power profile, you need to separate the measurable effects from the guesswork.

Linux power-draining on a laptop affects the whole hardware stack: from disk and GPU power, to frequent kernel wakeups, to profile-specific busy-wake daemon chatter. The differences between the Linux and Windows stacks come out in the power numbers.

The algorithm to save the most power hours from your baseline Linux system:

  1. Diagnose each component drain first, before tuning, using PowerTOP
  1. Check the device wakeups and enable runtime PM where possible
  1. Look at sources of frequent kernel interrupts, including Network, ACPI
  1. Measure wakeups by process or driver with PowerTOP and /sys/kernel/debug/pmc_core/
  1. Compare power states and substate requirements with uninterrupted sleep and freq_scaling_governor
  1. Check GPU power states when your card is still active in 'idle' profile

The core tools you need are built in to the Linux stack. PowerTOP, one of Linux's core power measurement and reporting tools, senses total and individual consumptions across the stack, and it suggests fixes for the biggest contributors from a measured baseline.

PowerTOP tabulates the biggest overall consuming processes and systems. Wherever faults fall on device, kernel timer, or user-space daemon, PowerTOP tells you. Its output orders the contributors by measured potential for savings, in descending rank.

But PowerTOP's role is in measurement, not tuning. It diagnoses where you should focus your tuning or kernel parameter checks. Whether you're targeting its power state suggestions, or a deeper dive into the kernel power structures, you first need them confirmed out of PowerTOP.

While PowerTOP locates the big power-consuming processes, it also pinpoints running devices that could be consuming more than they should. If just a handful are substate faulting, a switch in the kernel runtime power management might drop that overhead much faster than adding a background power saving script.

The Linux kernel's runtime PM is a stateful framework for switching running I/O devices to low-power mode. This usually switches off the device power when it is idle, then enables it back when the device needs to work again. The defer trigger between wake and idle restores device power, even overnight, without the whole system waking.

Most of the kernel runtime PM settings are found in the /sys/devices/ tree; often, you'll see the power managing state is powering switches or modes, rather than per-character devices. Let's say sdw0 is next to an SD card slot hardware interrupt. If you dig into its power settings, you'll get paths like /sys/devices/pci0000:00/0000:00:1a.0/typeC/sdw0/power/control, which accepts auto, on, or off for the device's runtime PM state.

The total runtime PM state for the device is usually set to a default state when it powers up. But that state might be very different from a nominal power saving mode, where the device either stops running altogether while the laptop's sitting on your desk, or lets it reduce overall power more deeply, to the substate power level configured for it.

There's a key runtime PM feature that shows overall substate usage and substate requirements, and it's found in kernel debug paths — not a user space path. The tool to check is called pmc_core and you'll find it in /sys/kernel/debug/pmc_core/. Monitor its substate_residencies and substate_requirements when your power profile switches, and you'll know all it does or doesn't do in low power mode.

For the full end pinning, you'll have to play with ACPI /sys/power/s3_test_break() and note which buffers tell PowerTOP to switch states after you run echo 1 > /sys/power/s3_test_break(). Start with the next hours of your sleep profile, and you'll know where device or timer wakeups are coming from. Port swaps and power rail pin-outs may create dangerous power levels, so be cautious about the choice of wake sources you disable. Find them first in PowerTOP.

One of the big battery-saving features for Intel graphics chips on Linux laptops hasn't found its way into PowerTOP yet. That's the Panel Self Refresh, or PSR, substate., it works by handing over the idle-screen power management to the display controller, cutting the usual screen-power draw to a a fraction of its running power.

Here's how to switch it on:

  1. Open PowerTOP's section 2 and inspect the i915_enable_psr configuration option
  1. Verify your kernel and your laptop graphics are compatible
  1. Add the i915.enable_psr=2 parameter to /boot/grub/menu.lst or /etc/default/grub, and redefine your boot loader configuration

The biggest battery drainers on Linux laptop systems are usually packed into hardware-wake-source processes, but the ranking depends on what you're doing. When you dig into power profiles, the right order of work is probably:

  1. Measure and diagnose with PowerTOP, then tune
  1. Optimize runtime PM on running devices (especially for card slots, break points, or new CPU paths)
  1. Inspect Network or Active Connection timers and interrupts (especially when wireless mode switches)
  1. Find chatty wake sources, kernel, daemon, and check wake events in /sys/kernel/debug/pmctl
  1. Inspect /sys/kernel/debug/pmc_core/substate_residencies and /sys/power/*
  2. Check power states in your GPU settings

These steps assume granular, local access, so they're probably overkill for a remote Linux server whose whole Stack runs power profiles. But for an old laptop running Linux, it's often effective.

Sources

More from the desk