Power Management in Linux – Advanced Tweaks: Kernel Parameters, GRUB, and Modprobe Options

Table of Contents

1. Introduction
   • Why tune power management?
   • Scope & audience
2. Prerequisites & Safety
   • Back-up & recovery
   • Test environment
   • Tools you need
3. Fundamentals
   • Linux power-management stack
   • Key kernel subsystems (cpuidle, cpufreq, runtime PM, PCIe ASPM, USB autosuspend)
4. Kernel Parameters (sysctl & /proc /sys)
   • Global sysctl knobs
   • /proc/sys/vm, /proc/sys/kernel
   • /sys/devices/system/cpu
   • Example “power-save” profile
5. GRUB – Boot-time Kernel Command Line
   • Anatomy of GRUB_CMDLINE_LINUX
   • Common power-saving options
   • CPU-frequency & idle tweaks
   • PCIe ASPM, USB, SATA, Wi-Fi, Bluetooth
   • Example GRUB configurations
   • Updating GRUB & regenerating initramfs
6. Modprobe – Module-specific Parameters
   • Overview of modprobe.d
   • Power-related modules (e.g., i915, radeon, amdgpu, thinkpad_acpi, snd_hda_intel, btusb)
   • Syntax & precedence
   • Sample files
7. Putting It All Together – A “Full-Power-Save” Profile
   • Step-by-step procedure
   • Verification with powertop, turbostat, systemd-analyze
8. Testing, Benchmarking & Roll-back
   • Stress testing
   • Measuring battery life
   • Reverting changes
9. Troubleshooting
   • Common symptoms
   • Log-based diagnostics
   • Kernel panics & boot loops
10. Advanced Topics
    • Dynamic runtime power management (DPM)
    • Using systemd power-saving services
    • Interaction with user-space tools (TLP, laptop-mode-tools, power-profiles-daemon)
11. FAQ
12. References & Further Reading
13. Appendix
    • Full example configuration files
    • Glossary of terms

1. Introduction

1.1 Why Tune Power Management?

• Battery life: Laptops, convertibles, and ARM‑based notebooks can gain 10‑30 % extra runtime with aggressive tuning.
• Thermal envelope: Lower power ⇒ cooler chassis ⇒ less fan noise and higher component longevity.
• Energy cost & carbon footprint: For servers, even a few watts saved per node add up in large farms.
• Performance vs. efficiency trade‑off: Advanced knobs let you define the exact point on the curve you need.

1.2 Scope & Audience

This manual assumes:

• A modern Linux distribution (kernel ≥ 6.0) using systemd and GRUB2.
• Familiarity with the command line, sudo, and basic system administration.
• A willingness to edit bootloader and kernel module configuration files.

It does not cover:

• User‑space power‑management utilities (TLP, power-profiles-daemon) – those are mentioned only for completeness.
• Firmware‑level (BIOS/UEFI) power‑policy configuration (though some BIOS knobs are referenced).

2. Prerequisites & Safety

2.1 Back‑up & Recovery

Tip: Keep a copy of the original kernel command line (cat /proc/cmdline) in a text file.

2.2 Test Environment

• Virtual machine (VM) – Great for syntax checking of GRUB & modprobe files, but power‑management hardware features are not exposed.
• Live USB – Boot a known‑good live system, then chroot into your installed system to apply changes safely.
• Dual‑boot fallback – Keep an older kernel entry in GRUB that boots without your custom options.

2.3 Tools You Need

sudo apt install -y git curl jq      # Debian/Ubuntu
sudo dnf install -y git curl jq       # Fedora
sudo pacman -S git curl jq            # Arch

• powertop – interactive power diagnostics.
• turbostat – per‑CPU frequency/power stats (requires linux-tools).
• systemd-analyze blame – identify services that may waste power.
• journalctl -b – review boot logs after changes.

3. Fundamentals

3.1 Linux Power‑Management Stack

Note: Most of these knobs are exposed via kernel command‑line parameters (GRUB) or via sysfs after boot. The manual covers both approaches.

3.2 Interaction with User‑Space

• systemd provides systemd-suspend, systemd-hibernate, and the power-profiles-daemon that expose “performance”, “balanced”, and “power‑save” profiles.
• powertop can “tune” many of the same parameters automatically; however, manual control via GRUB / modprobe is more deterministic and survives reboots without a daemon.

4. Kernel Parameters (sysctl & /proc /sys)

4.1 Global sysctl knobs

Add the above to /etc/sysctl.d/99-power.conf (create if missing):

# /etc/sysctl.d/99-power.conf
kernel.nmi_watchdog = 0
kernel.sched_rt_runtime_us = -1
vm.swappiness = 10
vm.laptop_mode = 5

Apply immediately:

sudo sysctl --system

4.2 /proc/sys/vm & /proc/sys/kernel

4.3 /sys/devices/system/cpu

4.3.1 CPU Frequency Scaling

# Set the default governor to "schedutil" (modern, combines load tracking & power)
sudo cpupower frequency-set -g schedutil

# Force a max performance percentage (e.g., limit to 80% of turbo)
echo 80 | sudo tee /sys/devices/system/cpu/cpufreq/policy0/max_perf_pct

You can make the setting persistent with a systemd service (/etc/systemd/system/cpufreq.service).

4.3.2 CPU Idle Governor

# Use "menu" idle governor (good balance) or "nop" to disable deep C‑states
echo menu | sudo tee /sys/devices/system/cpu/cpuidle/current_driver

4.4 Example “power‑save” profile (sysfs)

Create /etc/rc.local (or a systemd unit) that runs at boot:

#!/bin/sh
# /etc/rc.local – executed after multi‑user.target

# Reduce CPU C‑states to avoid latency spikes (optional)
for c in /sys/devices/system/cpu/cpu*/cpuidle/state*; do
    echo 0 > "$c/disable"
done

# Set all CPUs to powersave governor
for cpu in /sys/devices/system/cpu/cpu[0-9]*; do
    echo powersave > "$cpu/cpufreq/scaling_governor"
done

exit 0

Make it executable:

sudo chmod +x /etc/rc.local
sudo systemctl enable rc-local.service   # on Debian/Ubuntu

5. GRUB – Boot‑time Kernel Command Line

5.1 Anatomy of GRUB_CMDLINE_LINUX

The line is a space‑separated list of key=value pairs passed to the kernel at boot. Example:

GRUB_CMDLINE_LINUX="quiet splash intel_iommu=on pci=noaer"

Only the value part may be quoted if it contains spaces.

5.2 Common Power‑Saving Options

Caution: Some options (pcie_aspm=force, idle=nomwait, mitigations=off) can cause instability on specific hardware. Test thoroughly.

5.3 CPU‑frequency & Idle Tweaks

5.3.1 Disabling Intel SpeedStep (if you want a fixed low frequency)

GRUB_CMDLINE_LINUX="intel_pstate=disable"

5.3.2 Limiting Turbo Boost

GRUB_CMDLINE_LINUX="intel_pstate=no_hwp turbo_pct=70"

turbo_pct caps turbo to a percentage of the nominal maximum.

5.3.3 Using the “passive” mode (recommended for granular governor control)

GRUB_CMDLINE_LINUX="intel_pstate=passive"

After reboot, the cpufreq governors become visible (e.g., schedutil, powersave).

5.4 PCIe, USB, SATA, Wi‑Fi, Bluetooth

GRUB_CMDLINE_LINUX="pcie_aspm=force usbcore.autosuspend=2 sata_alpm=1 iwlwifi.power_save=1 iwlwifi.bt_coex_active=0 btusb.enable_autosuspend=1"

• iwlwifi.power_save=1 – Enables power‑save for Intel wireless.
• iwlwifi.bt_coex_active=0 – Disables Bluetooth coexistence (may improve Wi‑Fi power).

5.5 Example GRUB Configurations

5.5.1 “Balanced” (default)

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="intel_pstate=passive"

5.5.2 “Maximum Battery Life”

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="intel_pstate=passive processor.max_cstate=1 pcie_aspm=force usbcore.autosuspend=2 \
    iwlwifi.power_save=1 iwlwifi.bt_coex_active=0 btusb.enable_autosuspend=1 \
    i915.enable_psr=1 i915.enable_fbc=1 i915.enable_guc=2 amdgpu.runpm=1 \
    nvme_core.default_ps_max_latency_us=0"

5.5.3 “Performance (Desktop) – No Power Saving”

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="intel_pstate=disable turbo_pct=100"

5.6 Editing and Updating GRUB

On Debian‑based distros:

sudo nano /etc/default/grub
# edit the lines as above
sudo update-grub

On Fedora/CentOS (grub2-mkconfig):

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

After editing, reboot to apply.

5.7 Verifying the Parameters

After boot, run:

cat /proc/cmdline

You should see the exact string you set.

5.8 Override a GRUB parameters

The configuration file structure:

The /etc/default/grub.d/ directory contains shell script fragments that are sourced by grub-mkconfig. The configuration files are read in alphabetical order, and the final settings are combined before generating the grub.cfg file. 
This process works by using a shell variable expansion and concatenation. For example, to add a new kernel parameter, you do not replace the GRUB_CMDLINE_LINUX_DEFAULT variable; you append your new parameter to it using ${GRUB_CMDLINE_LINUX_DEFAULT}. 

How to override a GRUB parameter:

This procedure can be used to add or modify parameters like: pci=noaer

Create a new file in the /etc/default/grub.d/ directory. Use a descriptive name that ends in .cfg and starts with a number to control its execution order. A number like 50 or 90 is generally safe to ensure it is processed after any system defaults.

sudo nano /etc/default/grub.d/90-custom-params.cfg

Add the override logic to the new file. Use shell variable expansion to prepend or append your new parameters. To append a parameter: Append your new parameter to the existing value of GRUB_CMDLINE_LINUX_DEFAULT. This is the most common use case.

# 90-custom-params.cfg
GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_DEFAULT} pci=noaer"

To prepend a parameter: Some parameters need to be at the beginning of the list.

# 90-custom-params.cfg
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 ${GRUB_CMDLINE_LINUX_DEFAULT}"

6. modprobe – Kernel Module Parameters & Blacklisting

6.1 Why modprobe matters for power

Many drivers expose module parameters that can be set at load time (e.g., i915.enable_psr=1). These are supplied via a modprobe configuration file in /etc/modprobe.d/.

6.2 Syntax

File format: options <module> <key>=<value>.

Example /etc/modprobe.d/99-power.conf:

# /etc/modprobe.d/99-power.conf
options i915 enable_psr=1 enable_fbc=1 enable_guc=2
options amdgpu runpm=1
options nouveau powersave=1
options iwlwifi power_save=1 bt_coex_active=0
options snd_hda_intel power_save=1
options xhci_hcd autosuspend=1

6.3 Blacklisting Unwanted Modules

If a driver is known to prevent deep sleep (e.g., mei_me on some Intel platforms), blacklist it:

blacklist mei_me
blacklist mei

Add these lines to the same 99-power.conf file.

6.4 Persistent NVMe Power Settings

Create /etc/modprobe.d/nvme.conf:

options nvme_core default_ps_max_latency_us=0

6.5 GPU‑Specific Module Options

6.6 Reloading Module Options without Reboot

If you change a modprobe file, you can reload the module:

sudo modprobe -r i915
sudo modprobe i915

Warning: Unloading the graphics driver on an active X session will kill the display. Use a virtual console (Ctrl+Alt+F3) or reboot.

7. Verifying Power‑Saving Behaviour

7.1 Using powertop

sudo powertop --html=powertop-report.html

Open the HTML file in a browser; look for:

• CPU C‑states (C1, C2, …) – higher percentages indicate deeper sleep.
• GPU Power – Panel Self‑Refresh (PSR) should be active.
• PCIe ASPM – shows if ASPM is enabled.

7.2 Checking C‑state Limits

cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/disable

A 0 means the state is enabled.

7.3 Monitoring Battery Drain

Use upower or acpi:

upower -i $(upower -e | grep BAT)

Observe time to empty before and after changes.

7.4 Stress‑Testing for Stability

Run a short CPU stress test:

sudo apt install stress
stress --cpu 4 --timeout 120

Watch for freezes, excessive throttling, or kernel messages (dmesg | grep -i error).

Below is a fleshed‑out version of the sections you flagged as missing.
I kept the same numbering and titles you provided and expanded each bullet into a short‑to‑medium‑length paragraph (or a few paragraphs where appropriate). Feel free to trim, reorder, or add examples that match the rest of your document.

8. Testing, Benchmarking & Roll‑back

8.1 Stress testing

Before shipping a kernel or a power‑management configuration, you need to verify that the system remains stable under load. Typical stress‑testing tools include stress‑ng, sysbench, and Phoronix Test Suite. Run a mix of CPU, memory, I/O and GPU workloads while the power‑saving features (CPUFreq, runtime PM, autosuspend, etc.) are active. Monitor the kernel logs (dmesg -w), temperature sensors (sensors), and the power consumption (powertop or an external power meter). If you see frequent throttling, unexpected wake‑ups, or kernel oopses, isolate the offending component by toggling individual features.

8.2 Measuring battery life

Real‑world battery life is the ultimate metric for a laptop or embedded device. Use a repeatable workload (e.g., video playback, web browsing, compile‑heavy loops) and record the discharge curve with upower, acpi, or a dedicated power‑meter. The powertop --html report gives a nice visual of which devices are consuming the most power and how many wake‑ups they generate. For more scientific results, script the test so that the same sequence of actions (open a browser, start a video, run stress-ng --cpu 4) is performed on each build, then compute the average runtime until the battery reaches the shutdown threshold.

8.3 Reverting changes

Never assume a new kernel or config will work on every machine. Keep a rollback plan:

Document the exact git commit or package version you rolled back from, so you can reproduce the environment later.

9. Troubleshooting

9.1 Common symptoms

9.2 Log‑based diagnostics

1. Kernel ring buffer – dmesg -T (timestamps) or journalctl -k give the most immediate clues. Look for lines containing PM:, CPUFreq:, autosuspend, or any “failed to set power state” messages.
2. Systemd journal – journalctl -b -p 3 filters for warnings and errors from the current boot. You can also query a specific service, e.g., journalctl -u systemd-suspend.service.
3. Device‑specific logs – many drivers expose debugfs entries:
   • /sys/kernel/debug/pm_runtime – shows per‑device runtime‑PM usage counters.
   • /sys/kernel/debug/pm_trace – enables tracing of suspend/resume events (echo 1 > trace).

Collecting these logs before and after a reproducible step (e.g., plugging in a USB‑C dock) makes it far easier to spot the exact moment something goes wrong.

9.3 Kernel panics & boot loops

When a kernel panic occurs during early boot, you may only see a cryptic Kernel panic - not syncing: Fatal exception. Common culprits in the power‑management area are:

• Broken ACPI tables – try booting with acpi=off or acpi=noirq to see if the panic disappears. If it does, the problem is likely a buggy BIOS; file a bug report to the vendor.
• Mismatched CPUFreq governor – a governor that expects a missing cpufreq driver can cause a BUG: unable to handle kernel paging request. Verify that the appropriate driver (intel_pstate, acpi-cpufreq, or amd_pstate) is loaded.
• Incorrect device tree / platform data – on ARM boards, a missing compatible string can cause the runtime‑PM core to dereference a null pointer.

Recovery steps:

1. Boot into an older kernel (GRUB → “Advanced options”).
2. Add init=/bin/sh to the kernel command line to drop into a minimal shell before most services start.
3. Mount the root filesystem read‑write (mount -o remount,rw /).
4. Undo the last change (e.g., restore the original cpufreq driver, revert a modprobe.d blacklist, or delete a broken systemd override).
5. Reboot and verify the system boots cleanly.

10. Advanced Topics

10.1 Dynamic runtime power management (DPM)

Modern kernels (≥ 5.4) expose Dynamic DPM for GPUs, NVMe, and other high‑performance devices. DPM works by exposing a set of performance states (P‑states) that the runtime‑PM core can switch between based on utilization. To enable it:

# For AMD GPU
echo "1" > /sys/class/drm/card0/device/power_dpm_state   # "performance" or "battery"
echo "auto" > /sys/class/drm/card0/device/power_dpm_force_performance_level

The kernel automatically selects the lowest power state that satisfies the current workload. You can fine‑tune thresholds via /sys/module/amdgpu/parameters/dpm_forced_performance_level. Similar interfaces exist for Intel i915 (/sys/class/drm/card0/power_profile) and for NVMe (/sys/block/nvme0n1/power/control).

10.2 Using systemd power‑saving services

systemd ships a collection of power‑saving units that can be enabled or disabled per‑profile:

You can also create custom targets (power-saving.target) that pull in a set of services (e.g., disabling Bluetooth, lowering screen brightness, switching to a low‑power CPU governor) and then systemctl isolate power-saving.target before a long‑run battery test.

10.3 Interaction with user‑space tools

When you enable more than one of these tools, be mindful of conflict zones (CPU governor, USB autosuspend, PCIe ASPM). The safest approach is to pick a primary manager (e.g., TLP) and disable the overlapping modules in the others (/etc/laptop-mode/conf.d/disable.conf, powerprofilesctl profile overrides, etc.).

11 . FAQ

12. References & Further Reading

13 Appendix

A. Full example configuration files

/etc/tlp.conf (excerpt)

# TLP 1.6 configuration
# -------------------------------------------------------------------
# CPU scaling governor (on battery)
CPU_SCALING_GOVERNOR_ON_BAT=power-saver
# Minimum/maximum frequencies (kHz)
CPU_MIN_FREQ_ON_BAT=800000
CPU_MAX_FREQ_ON_BAT=1800000

# USB autosuspend
USB_AUTOSUSPEND=1
USB_BLACKLIST_BTUSB=1   # disable autosuspend for Bluetooth dongle

# Wi‑Fi power saving
WIFI_PWR_ON_BAT=5       # 5 = enable power save

# PCI Express Active State Power Management
PCI_EXPRESS_ASPM_ON_BAT=ondemand

# Runtime PM for SATA
SATA_LINKPWR_ON_BAT=min_power

/etc/systemd/sleep.conf.d/10-custom.conf

[Sleep]
SuspendMode=freeze
HibernateMode=shutdown

/etc/udev/rules.d/99-usb-autosuspend.rules

# Keep external docking stations always powered (vendor:product)
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1234", ATTR{idProduct}=="abcd", ATTR{autosuspend}="-1"

B. Glossary of terms