Power management - ArchWiki

Jump to content
From ArchWiki

Related articles

- Power management/Suspend and hibernate
- Power management/Wakeup triggers
- Display Power Management Signaling
- CPU frequency scaling
- Hybrid graphics
- Kernel modules
- sysctl
- udev

Power management is a feature that turns off the power or switches system components to a low-power state when inactive.

In Arch Linux, power management consists of two main parts:

1. Configuration of the Linux kernel, which interacts with the hardware.
   - Kernel parameters
   - Kernel modules
   - udev rules
2. Configuration of userspace tools, which interact with the kernel and react to its events. Many userspace tools also allow to modify kernel configuration in a "user-friendly" way. See #Userspace tools for the options.

## Userspace tools

Using these tools can replace setting a lot of settings by hand. Only run one of these tools to avoid possible conflicts as they all work more or less similarly. Have a look at the power management category to get an overview on what power management options exist in Arch Linux.

These are the more popular scripts and tools designed to help power saving:

### Console

- acpid — A daemon for delivering ACPI power management events with netlink support.

  https://sourceforge.net/projects/acpid2/ || acpid

- Laptop Mode Tools — Utility to configure laptop power saving settings, considered by many to be the de facto utility for power saving though may take a bit of configuration.

  https://github.com/rickysarraf/laptop-mode-tools || laptop-mode-toolsAUR

- libsmbios — Library and tools for interacting with Dell SMBIOS tables.

  https://github.com/dell/libsmbios || libsmbios

- powertop — A tool to diagnose issues with power consumption and power management to help set power saving settings.

  https://github.com/fenrus75/powertop || powertop

- systemd — A system and service manager.

  https://freedesktop.org/wiki/Software/systemd/ || systemd

- TLP — Advanced power management for Linux.

  https://linrunner.de/tlp || tlp

### Graphical

- batsignal — Lightweight battery monitor that uses libnotify to warn of low battery levels.

  https://github.com/electrickite/batsignal || batsignalAUR

- cbatticon — Lightweight and fast battery icon that sits in your system tray.

  https://github.com/valr/cbatticon || cbatticon

- GNOME Power Statistics — System power information and statistics for GNOME.

  https://gitlab.gnome.org/GNOME/gnome-power-manager || gnome-power-manager

- KDE Power Devil — Power management module for Plasma.

  https://invent.kde.org/plasma/powerdevil || powerdevil

- LXQt Power Management — Power management module for LXQt.

  https://github.com/lxqt/lxqt-powermanagement || lxqt-powermanagement

- MATE Power Management — Power management tool for MATE.

  https://github.com/mate-desktop/mate-power-manager || mate-power-manager

- MATE Power Statistics — System power information and statistics for MATE.

  https://github.com/mate-desktop/mate-power-manager || mate-power-manager

- poweralertd — Daemon for delivering UPower notifications.

  https://git.sr.ht/~kennylevinsen/poweralertd || poweralertdAUR

- powerkit — Desktop independent power manager.

  https://github.com/rodlie/powerkit || powerkitAUR

- Xfce Power Manager — Power manager for Xfce.

  https://docs.xfce.org/xfce/xfce4-power-manager/start || xfce4-power-manager

- vattery — Battery monitoring application written in Vala that will display the status of a laptop battery in a system tray.

  https://www.jezra.net/projects/vattery.html || vatteryAUR

## Power management

### ACPI events

systemd handles some power-related ACPI events, whose actions can be configured in `/etc/systemd/logind.conf` or `/etc/systemd/logind.conf.d/*.conf` — see logind.conf(5). On systems with no dedicated power manager, this may replace the acpid daemon which is usually used to react to these ACPI events.

The specified action for each event can be one of `ignore`, `poweroff`, `reboot`, `halt`, `suspend`, `hibernate`, `hybrid-sleep`, `suspend-then-hibernate`, `lock` or `kexec`. In case of hibernation and suspension, they must be properly set up. If an event is not configured, systemd will use a default action.

Event handler | Description | Default action
--- | --- | ---
`HandlePowerKey` | Triggered when the power key/button is pressed. | `poweroff`
`HandleSuspendKey` | Triggered when the suspend key/button is pressed. | `suspend`
`HandleHibernateKey` | Triggered when the hibernate key/button is pressed. | `hibernate`
`HandleLidSwitch` | Triggered when the lid is closed, except in the cases below. | `suspend`
`HandleLidSwitchDocked` | Triggered when the lid is closed if the system is inserted in a docking station, or more than one display is connected. | `ignore`
`HandleLidSwitchExternalPower` | Triggered when the lid is closed if the system is connected to external power. | action set for `HandleLidSwitch`

To apply changes, reload `systemd-logind.service`.

Note: systemd cannot handle AC and Battery ACPI events, so if you use Laptop Mode Tools or other similar tools acpid is still required.

#### Power managers

Some desktop environments include power managers which inhibit (temporarily turn off) some or all of the systemd ACPI settings. If such a power manager is running, then the actions for ACPI events can be configured in the power manager alone. Changes to `/etc/systemd/logind.conf` or `/etc/systemd/logind.conf.d/*.conf` need be made only if you wish to configure behaviour for a particular event that is not inhibited by the power manager.

Note that if the power manager does not inhibit systemd for the appropriate events you can end up with a situation where systemd suspends your system and then when the system is woken up the other power manager suspends it again. The power managers of KDE, GNOME, Xfce and MATE issue the necessary inhibited commands. If the inhibited commands are not being issued, such as when using acpid or others to handle ACPI events, set the `Handle` options to `ignore`. See also systemd-inhibit(1).

#### xss-lock

xss-lock subscribes to the systemd-events `suspend`, `hibernate`, `lock-session`, and `unlock-session` with appropriate actions (run locker and wait for user to unlock or kill locker). xss-lock also reacts to DPMS events and runs or kills the locker in response.

Autostarting the following for example:

    $ xss-lock -- i3lock -n -i background_image.png &

### Suspend and hibernate

systemd provides commands to suspend to RAM or hibernate using the kernel's native suspend/resume functionality. There are also mechanisms to add hooks to customize pre- and post-suspend actions.

`systemctl suspend` should work out of the box, for `systemctl hibernate` to work on your system you need to follow the instructions at Suspend and hibernate#Hibernation.

There are also two modes combining suspend and hibernate:

- `systemctl hybrid-sleep` suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called suspend to both.
- `systemctl suspend-then-hibernate` initially suspends the system to RAM as long as possible, then wakes it with an RTC alarm and hibernates. The RTC alarm is set with `HibernateDelaySec` in systemd-sleep.conf(5). The default value is set by estimating the battery discharge rate to keep the system with 5% of battery, or two hours without one. Said estimation is obtained from the change in battery level after the time specified by `SuspendEstimationSec` in systemd-sleep.conf(5), at which the system will briefly wake up to do the measurement (a measure is also made if the system is manually woken up from suspension).

#### Disabling suspend

When using a device as e.g a server, suspending might not be needed or it could even be undesired. Any sleep state can be configured:

    /etc/systemd/sleep.conf.d/disable-suspend.conf

    [Sleep]
    AllowSuspend=no
    AllowHibernation=no
    AllowSuspendThenHibernate=no
    AllowHybridSleep=no

### Sleep hooks

#### Suspend/resume service files

Service files can be hooked into suspend.target, hibernate.target, sleep.target, hybrid-sleep.target and suspend-then-hibernate.target to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. Enable the `suspend@user` and `resume@user` services to have them started at boot. Examples:

    /etc/systemd/system/suspend@.service

    [Unit]
    Description=User suspend actions
    Before=sleep.target

    [Service]
    User=%I
    Type=forking
    Environment=DISPLAY=:0
    ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop
    ExecStart=/usr/bin/sflock
    ExecStartPost=/usr/bin/sleep 1

    [Install]
    WantedBy=sleep.target

    /etc/systemd/system/resume@.service

    [Unit]
    Description=User resume actions
    After=suspend.target

    [Service]
    User=%I
    Type=simple
    ExecStart=/usr/local/bin/ssh-connect.sh

    [Install]
    WantedBy=suspend.target

Note: As screen lockers may return before the screen is "locked", the screen may flash on resuming from suspend. Adding a small delay via `ExecStartPost=/usr/bin/sleep 1` helps prevent this.

For root/system actions (enable the `root-resume` and `root-suspend` services to have them started at boot):

    /etc/systemd/system/root-suspend.service

    [Unit]
    Description=Local system suspend actions
    Before=sleep.target

    [Service]
    Type=simple
    ExecStart=-/usr/bin/pkill sshfs

    [Install]
    WantedBy=sleep.target

    /etc/systemd/system/root-resume.service

    [Unit]
    Description=Local system resume actions
    After=suspend.target

    [Service]
    Type=simple
    ExecStart=/usr/bin/systemctl restart mnt-media.automount

    [Install]
    WantedBy=suspend.target

Tip: A couple of handy hints about these service files (more in systemd.service(5)):

- If `Type=oneshot` then you can use multiple `ExecStart=` lines. Otherwise only one `ExecStart` line is allowed. You can add more commands with either `ExecStartPre` or by separating commands with a semicolon (see the first example above; note the spaces before and after the semicolon, as they are required).
- A command prefixed with `-` will cause a non-zero exit status to be ignored and treated as a successful command.
- The best place to find errors when troubleshooting these service files is of course with journalctl.

#### Combined suspend/resume service file

With the combined suspend/resume service file, a single hook does all the work for different phases (sleep/resume) and for different targets (suspend/hibernate/hybrid-sleep).

Example and explanation:

    /etc/systemd/system/wicd-sleep.service

    [Unit]
    Description=Wicd sleep hook
    Before=sleep.target
    StopWhenUnneeded=yes

    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=-/usr/share/wicd/daemon/suspend.py
    ExecStop=-/usr/share/wicd/daemon/autoconnect.py

    [Install]
    WantedBy=sleep.target

- `RemainAfterExit=yes`: After started, the service is considered active until it is explicitly stopped.
- `StopWhenUnneeded=yes`: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after sleep.target is stopped.
- Because sleep.target is pulled in by suspend.target, hibernate.target and hybrid-sleep.target and because sleep.target itself is a StopWhenUnneeded service, the hook is guaranteed to start/stop properly for different tasks.

##### Generic service template

In this example, we create a template service which we can then use to hook any existing systemd service to power events:[1]

    /etc/systemd/system/sleep@.service

    [Unit]
    Description=%I sleep hook
    Before=sleep.target
    StopWhenUnneeded=yes

    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=-/usr/bin/systemctl stop %i
    ExecStop=-/usr/bin/systemctl start %i

    [Install]
    WantedBy=sleep.target

Then enable an instance of this template by specifying the basename of an existing systemd service after the `@`, i.e., `sleep@service-file-basename.service`. See systemd.unit(5) § DESCRIPTION for more details on templates.

Tip: Templates are not limited to systemd services and can be used with other programs. See [2] for some examples.

#### Hooks in /usr/lib/systemd/system-sleep

systemd runs all executables in `/usr/lib/systemd/system-sleep/`, passing two arguments to each of them:

- Argument 1: either `pre` or `post`, depending on whether the machine is going to sleep or waking up
- Argument 2: `suspend`, `hibernate` or `hybrid-sleep`, depending on which is being invoked

systemd will run these scripts concurrently and not one after another.

The output of any custom script will be logged by systemd-suspend.service, systemd-hibernate.service or systemd-hybrid-sleep.service. You can see its output in systemd's journalctl:

    # journalctl -b -u systemd-suspend.service

Note: You can also use sleep.target, suspend.target, hibernate.target or hybrid-sleep.target to hook units into the sleep state logic instead of using custom scripts.

An example of a custom sleep script:

    /usr/lib/systemd/system-sleep/example.sh

    #!/bin/sh
    case $1/$2 in
      pre/*)
        echo "Going to $2..."
        ;;
      post/*)
        echo "Waking up from $2..."
        ;;
    esac

Do not forget to make your script executable.

See systemd.special(7) and systemd-sleep(8) for more details.

### Troubleshooting

#### Delayed lid switch action

When performing lid switches in short succession, logind will delay the suspend action for up to 90s to detect possible docks. [3] This delay was made configurable with systemd v220:[4]

    /etc/systemd/logind.conf

    ...
    HoldoffTimeoutSec=30s
    ...

#### Suspend from corresponding laptop Fn key not working

If, regardless of the setting in logind.conf, the sleep button does not work (pressing it does not even produce a message in syslog), then logind is probably not watching the keyboard device. [5] Do:

    # journalctl --grep="Watching system buttons"

You might see something like this:

    May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event2 (Power Button)
    May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event3 (Sleep Button)
    May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event4 (Video Bus)

Notice no keyboard device. List keyboard devices as follows:

    $ stat -c%N /dev/input/by-id/*-kbd

    ...
    /dev/input/by-id/usb-SIGMACHIP_USB_Keyboard-event-kbd -> ../event6
    ...

Now obtain `ATTRS{name}` for the parent keyboard device [6]. As an example, on the above list this keyboard device has `event6` as device input event, it can be used to search its respective attribute name:

    # udevadm info -a /dev/input/event6

    ...
    KERNEL=="event6"
    ...
    ATTRS{name}=="SIGMACHIP USB Keyboard"

Now write a custom udev rule to add the "power-switch" tag:

    /etc/udev/rules.d/70-power-switch-my.rules

    ACTION=="remove", GOTO="power_switch_my_end"
    SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="SIGMACHIP USB Keyboard", TAG+="power-switch"
    LABEL="power_switch_my_end"

Restart `systemd-udevd.service`, reload rules by running `udevadm trigger` as root, and restart `systemd-logind.service`.

Now you should see `Watching system buttons on /dev/input/event6` in syslog.

#### PC will not wake from sleep on A520I and B550I motherboards

On some motherboards with A520i and B550i chipsets, the system will not completely enter the sleep state or come out of it. Symptoms include the system entering sleep and the monitor turning off while internal LEDs on the motherboard or the power LED stay on. Subsequently, the system will not come back from this state and require a hard power off. If you have similar issues with AMD, first make sure your system is fully updated and check whether the AMD microcode package is installed.

Verify the line starting with `GPP0` has the enabled status:

    $ cat /proc/acpi/wakeup

    Device	S-state	  Status   Sysfs node
    GP12	  S4	*enabled   pci:0000:00:07.1
    GP13	  S4	*enabled   pci:0000:00:08.1
    XHC0	  S4	*enabled   pci:0000:0b:00.3
    GP30	  S4	*disabled
    GP31	  S4	*disabled
    PS2K	  S3	*disabled
    GPP0	  S4	*enabled   pci:0000:00:01.1
    GPP8	  S4	*enabled   pci:0000:00:03.1
    PTXH	  S4	*enabled   pci:0000:05:00.0
    PT20	  S4	*disabled
    PT24	  S4	*disabled
    PT26	  S4	*disabled
    PT27	  S4	*disabled
    PT28	  S4	*enabled   pci:0000:06:08.0
    PT29	  S4	*enabled   pci:0000:06:09.0

If that is enabled, you can run the following command:

    # echo GPP0 > /proc/acpi/wakeup

Now test by running `systemctl suspend` and let the system go to sleep. Then try to wake the system after a few seconds. If it works, you can make the workaround permanent. Create a systemd unit file:

    /etc/systemd/system/toggle-gpp0-to-fix-wakeup.service

    [Unit]
    Description="Disable GPP0 to fix suspend issue"

    [Service]
    ExecStart=/bin/sh -c "/bin/echo GPP0 > /proc/acpi/wakeup"

    [Install]
    WantedBy=multi-user.target

Do a daemon-reload and start/enable the newly created unit.

Alternatively, you can create a udev rule. Assuming `GPP0`’s sysfs node is `pci:0000:00:01.1` like in the example, run `udevadm info -a -p /sys/bus/pci/devices/0000\:00\:01.1` to get the relevant information and create a udev rule like this one:

    /etc/udev/rules.d/10-gpp0-acpi-fix.rules

    KERNEL=="0000:00:01.1", SUBSYSTEM=="pci", DRIVERS=="pcieport", ATTR{vendor}=="0x1022", ATTR{device}=="0x1483", ATTR{power/wakeup}="disabled"

The factual accuracy of this article or section is disputed.

Reason: What is the point of reloading udev before reboot? The previous variants do not instruct to reboot. (Discuss in Talk:Power management)

Then reload the rules with `udevadm control --reload` and reboot the system.

### Tips and tricks

#### On-demand swap for hibernation only

The factual accuracy of this article or section is disputed.

Reason: The rationale behind this is weak. If the swap space exists, why not just keep it activated? And suggesting setting something dangerous (`SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1`) makes this even more inappropriate. [7] (Discuss in Talk:Power management#On-demand swap for hibernation only)

In some setups it might be desired to have the swap area activated only for the hibernation and deactivated again after resume.

While this could be achieved via the hooks described above, it is also possible to directly use a swap unit configuration (see systemd.swap(5)) like the following:

    /etc/systemd/system/path-to-swap.swap

    [Unit]
    Before=systemd-hibernate.service
    StopWhenUnneeded=true

    [Swap]
    What=/path/to/swap
    Options=noauto

    [Install]
    RequiredBy=systemd-hibernate.service

Note:

- The unit filename must correspond to the pathname of the swap device (or file) and the unit must be enabled for `RequiredBy=` to have an effect.
- It would also be possible to depend on `hibernate.target` rather than `systemd-hibernate.service`, but then a direct `systemctl start systemd-hibernate.service` would not work.
- Desktop environments might not show the option to hibernate and `systemctl hibernate` will not work, because these query `systemd-logind` for the available power-saving modes and that will not advertise hibernation unless a swap-area is active. This can be circumvented by starting `systemd-logind` with the variable `SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1` in its environment, for example via a drop-in file like:

    /etc/systemd/system/systemd-logind.service.d/disable-hibernation-swap-check.conf

    [Service]
    Environment="SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1"

## Power saving

Note: See Laptop#Power management for power management specific to laptops, such as battery monitoring. See also pages specific to your CPU and GPU (e.g., Ryzen, AMDGPU).

This section is a reference for creating custom scripts and power saving settings such as by udev rules. Make sure that the settings are not managed by some other utility to avoid conflicts.

Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to dynamic overclocking.

### Processors with Intel HWP (Intel Hardware P-state) support

This article or section is a candidate for merging with CPU frequency scaling.

Notes: More context in the main article. (Discuss in Talk:Power management)

The available energy preferences of a HWP supported processor are `default`, `performance`, `balance_performance`, `balance_power`, `power`.

This can be validated by running

    $ cat /sys/devices/system/cpu/cpufreq/policy*/energy_performance_available_preferences

To conserve more energy, you can configuration by creating the following file:

    /etc/tmpfiles.d/energy_performance_preference.conf

    w /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference - - - - balance_power

See the x86_energy_perf_policy(8) man page for more details on energy-performance policy in Intel processors. Also see systemd-tmpfiles(8) and tmpfiles.d(5) man pages for temporary files/directories details.

### Audio

#### Kernel

By default, audio power saving is turned off by most drivers. It can be enabled by setting the `power_save` parameter; a time (in seconds) to go into idle mode. To idle the audio card after one second, create the following file for Intel soundcards.

    /etc/modprobe.d/audio_powersave.conf

    options snd_hda_intel power_save=1

Alternatively, use the following for ac97:

    options snd_ac97_codec power_save=1

Note:

- To retrieve the manufacturer and the corresponding kernel driver which is used for your sound card, run `lspci -k`.
- Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.

It is also possible to further reduce the audio power requirements by disabling the HDMI audio output, which can done by blacklisting the appropriate kernel modules (e.g. `snd_hda_codec_hdmi` in case of Intel hardware).

#### PulseAudio

By default, PulseAudio suspends any audio sources that have become idle for too long. When using an external USB microphone, recordings may start with a pop sound. As a workaround, comment out the following line in `/etc/pulse/default.pa`:

    load-module module-suspend-on-idle

Afterwards, restart PulseAudio with `systemctl restart --user pulseaudio`.

### Backlight

See Backlight.

### Bluetooth

To disable bluetooth completely, blacklist the `btusb` and `bluetooth` modules.

To turn off bluetooth only temporarily, use rfkill:

    # rfkill block bluetooth

Or with udev rule:

    /etc/udev/rules.d/50-bluetooth.rules

    # disable bluetooth
    SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"

### Web camera

If you will not use integrated web camera then blacklist the `uvcvideo` module.

### Kernel parameters

This section uses configurations in `/etc/sysctl.d/`, which is "a drop-in directory for kernel sysctl parameters." See The New Configuration Files and more specifically sysctl.d(5) for more information.

#### Disabling NMI watchdog

This article or section needs expansion.

Reason: This or `nowatchdog` as can be seen in Improving performance#Watchdogs (Discuss in Talk:Power management)

The NMI watchdog is a debugging feature to catch hardware hangs that cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage:

    /etc/sysctl.d/disable_watchdog.conf

    kernel.nmi_watchdog = 0

or add `nmi_watchdog=0` to the kernel line to disable it completely from early boot.

#### Writeback Time

Increasing the virtual memory dirty writeback time helps to aggregate disk I/O together, thus reducing spanned disk writes, and increasing power saving. To set the value to 60 seconds (default is 5 seconds):

    /etc/sysctl.d/dirty.conf

    vm.dirty_writeback_centisecs = 6000

To do the same for journal commits on supported filesystems (e.g. ext4, btrfs...), use `commit=60` as a option in fstab.

Note that this value is modified as a side effect of the Laptop Mode setting below. See also sysctl#Virtual memory for other parameters affecting I/O performance and power saving.

#### Laptop Mode

See the kernel documentation on the laptop mode "knob" - "A sensible value for the knob is 5 seconds".

    /etc/sysctl.d/laptop.conf

    vm.laptop_mode = 5

Note: This setting is mainly relevant to spinning-disk drives.

### Network interfaces

Wake-on-LAN can be a useful feature, but if you are not making use of it then it is simply draining extra power waiting for a magic packet while in suspend. You can adapt the Wake-on-LAN#udev rule to disable the feature for all ethernet interfaces. To enable powersaving with iw on all wireless interfaces:

    /etc/udev/rules.d/81-wifi-powersave.rules

    ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"

The name of the configuration file is important. With the use of persistent device names in systemd, the above network rule, named lexicographically after `80-net-setup-link.rules`, is applied after the device is renamed with a persistent name e.g. `wlan0` renamed `wlp3s0`. Be aware that the `RUN` command is executed after all rules have been processed and must anyway use the persistent name, available in `$name` for the matched device.

#### Intel wireless cards (iwlwifi)

Additional power saving functions of Intel wireless cards with `iwlwifi` driver can be enabled by passing the correct parameters to the kernel module. Making them persistent can be achieved by adding the lines below to the `/etc/modprobe.d/iwlwifi.conf` file:

    options iwlwifi power_save=1

This option will probably increase your median latency:

    options iwlwifi uapsd_disable=0

On kernels < 5.4 you can use this option, but it will probably decrease your maximum throughput:

    options iwlwifi d0i3_disable=0

Depending on your wireless card one of these two options will apply.

    options iwlmvm power_scheme=3

    options iwldvm force_cam=0

You can check which one is relevant by checking which of these modules is running using

    # lsmod | grep '^iwl.vm'

Keep in mind that these power saving options are experimental and can cause an unstable system.

### Bus power management

#### Active State Power Management

From Wikipedia:

  Active-state power management (ASPM) is a power management mechanism for PCI Express devices to garner power savings while otherwise in a fully active state. Predominantly, this is achieved through active-state link power management; i.e., the PCI Express serial link is powered down when there is no traffic across it. It is normally used on laptops and other mobile Internet devices to extend battery life.

At boot, the BIOS enables or disables ASPM based on hardware support. To check for support:

    # lspci -vv | grep 'ASPM.*abled;'

Fetch available ASPM policies and the current system default using the following:

    $ cat /sys/module/pcie_aspm/parameters/policy

    [default] performance powersave powersupersave

ASPM might be disabled for the following reasons [8]:

1. The BIOS disabled it for some reason (for conflicts?).
2. PCIE requires ASPM but L0s are optional (so L0s might be disabled and only L1 enabled).
3. The BIOS might not have been programmed for it or may be buggy.

If you believe that your hardware has support for ASPM despite the above, it can be force-enabled for the kernel to handle with the `pcie_aspm=force` kernel parameter.

Warning:

- Force-enabling ASPM on an unsupported system may lead to increased power consumption. Furthermore, it may cause system freezes or kernel panics, so make sure you have a way to undo the option if it is unsuitable.
- Forcing ASPM takes place in the kernel, and therefore it may still remain disabled in hardware and not work. To check whether this is the case, run `dmesg | grep ASPM` as root. Consult the Wiki article specific to your hardware for more information if possible.

As long as ASPM is supported and enabled, it is possible to select a desired policy for the current session. For example, switch to `powersupersave` for the current session by doing the following:

    # echo powersave > /sys/module/pcie_aspm/parameters/policy

To configure a specific ASPM state to enable upon system boot (using `powersupersave` as an example), add `pcie_aspm.policy=powersupersave` as a kernel parameter.

#### PCI Runtime Power Management

    /etc/udev/rules.d/pci_pm.rules

    SUBSYSTEM=="pci", ATTR{power/control}="auto"

The rule above powers all unused devices down, but some devices will not wake up again. To allow runtime power management only for devices that are known to work, use simple matching against vendor and device IDs (use `lspci -nn` to get these values):

    /etc/udev/rules.d/pci_pm.rules

    # whitelist for pci autosuspend
    SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="auto"

Alternatively, to blacklist devices that are not working with PCI runtime power management and enable it for all other devices:

    /etc/udev/rules.d/pci_pm.rules

    # blacklist for pci runtime power management
    SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="on", GOTO="pci_pm_end"

    SUBSYSTEM=="pci", ATTR{power/control}="auto"
    LABEL="pci_pm_end"

#### USB autosuspend

The Linux kernel can automatically suspend USB devices when they are not in use. This can sometimes save quite a bit of power, however some USB devices are not compatible with USB power saving and start to misbehave (common for USB mice/keyboards). udev rules based on whitelist or blacklist filtering can help to mitigate the problem.

The most simple and likely useless example is enabling autosuspend for all USB devices:

    /etc/udev/rules.d/50-usb_power_save.rules

    ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"

To allow autosuspend only for devices that are known to work, use simple matching against vendor and product IDs (use lsusb to get these values):

    /etc/udev/rules.d/50-usb_power_save.rules

    # whitelist for usb autosuspend
    ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/control}="auto"

Alternatively, to blacklist devices that are not working with USB autosuspend and enable it for all other devices:

    /etc/udev/rules.d/50-usb_power_save.rules

    # blacklist for usb autosuspend
    ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", GOTO="power_usb_rules_end"

    ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
    LABEL="power_usb_rules_end"

The default autosuspend idle delay time is controlled by the `autosuspend` parameter of the `usbcore` built-in kernel module. To set the delay to 5 seconds instead of the default 2 seconds, add the following kernel parameter for your boot loader.

    usbcore.autosuspend=5

Similarly to `power/control`, the delay time can be fine-tuned per device by setting the `power/autosuspend` attribute. This means, alternatively, autosuspend can be disabled by setting `power/autosuspend` to -1 (i.e., never autosuspend):

    /etc/udev/rules.d/50-usb_power_save.rules

    ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/autosuspend}="-1"

See the Linux kernel documentation for more information on USB power management.

#### SATA Active Link Power Management

Warning: SATA Active Link Power Management can lead to data loss on some devices. Do not enable this setting unless you have frequent backups.

This article or section is out of date.

Reason: Phrases like "new setting" and "will become a default setting" are outdated. Also should be more formal. See Help:Style#Language register. (Discuss in Talk:Power management)

Since Linux 4.15 there is a new setting called `med_power_with_dipm` that matches the behaviour of Windows IRST driver settings and should not cause data loss with recent SSDs or HDDs. The power saving can be significant, ranging from 1.0 to 1.5 Watts (when idle). It will become a default setting for Intel based laptops in Linux 4.16 [9].

The current setting can be read from `/sys/class/scsi_host/host*/link_power_management_policy` as follows:

    $ cat /sys/class/scsi_host/host*/link_power_management_policy

Available ALPM settings
Setting | Description | Power saving
--- | --- | ---
max_performance | current default | None
medium_power | - | ~1.0 Watts
med_power_with_dipm | recommended setting | ~1.5 Watts
min_power | WARNING: possible data loss | ~1.5 Watts

    /etc/udev/rules.d/hd_power_save.rules

    ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="med_power_with_dipm"

Note: This adds latency when accessing a drive that has been idle, so it is one of the few settings that may be worth toggling based on whether you are on AC power.

### Hard disk drive

See hdparm#Power management configuration for drive parameters that can be set.

Power saving is not effective when too many programs are frequently writing to the disk. Tracking all programs, and how and when they write to disk is the way to limit disk usage. Use iotop to see which programs use the disk frequently. See Improving performance#Storage devices for other tips.

Small adjustments such as setting the noatime option can also help. If enough RAM is available, consider disabling or limiting swappiness as it has the possibility to limit a good number of disk writes.

For Seagate drives with PowerChoice technology, tricks setting APM via hdparm will not work due to the EPC (Extended Power Conditions) feature. Rather than setting APM, you can install openseachestAUR and fully disable EPC like so (replace X with actual drive letter):

    # openSeaChest_PowerControl --scan
    # openSeaChest_PowerControl -d /dev/sdX -i
    # openSeaChest_PowerControl -d /dev/sdX --showEPCSettings
    # openSeaChest_PowerControl -d /dev/sdX --EPCfeature disable
    # openSeaChest_PowerControl -d /dev/sdX --showEPCSettings

Last invocation will give the following summary:

    ==========================================================================================
     openSeaChest_PowerControl - openSeaChest drive utilities - NVMe Enabled
     Copyright (c) 2014-2023 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
     openSeaChest_PowerControl Version: 3.3.1-4_1_1 X86_64
     Build Date: Jul  4 2023
     Today: Tue Jul  4 17:49:36 2023        User: root
    ==========================================================================================

    /dev/sdX - ST1000NM0008-2F2100 - ZFA19JG2 - SN02 - ATA

    ===EPC Settings===
            * = timer is enabled
            C column = Changeable
            S column = Savable
            All times are in 100 milliseconds

    Name       Current Timer Default Timer Saved Timer   Recovery Time C S
    Idle A      0            *10           *10           1             Y Y
    Idle B      0            *1200         *1200         3             Y Y
    Idle C      0             6000          6000         16            Y Y
    Standby Z   0             9000          9000         46            Y Y

Zeroes in the first column confirm that parking and spindown were disabled successfully

## Tools and scripts

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: Merged from Power saving, needs reorganization to fit into this page. (Discuss in Talk:Power management)

### Using a script and an udev rule

This article or section is a candidate for merging with Laptop#Power management.

Notes: Might be a better fit for the laptop-specific page. (Discuss in Talk:Power management)

Since systemd users can suspend and hibernate through `systemctl suspend` or `systemctl hibernate` and handle acpi events with `/etc/systemd/logind.conf`, it might be interesting to remove pm-utils and acpid. There is just one thing systemd cannot do (as of systemd-204): power management depending on whether the system is running on AC or battery. To fill this gap, you can create a single udev rule that runs a script when the AC adapter is plugged and unplugged:

    /etc/udev/rules.d/powersave.rules

    SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"
    SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"

Note: You can use the same script that pm-powersave uses. You just have to make it executable and place it somewhere else (for example `/usr/local/bin/`).

Examples of powersave scripts:

- ftw, package: ftw-gitAUR
- powersave
- throttlectl, from throttlectlAUR

The above udev rule should work as expected, but if your power settings are not updated after a suspend or hibernate cycle, you should add a script in `/usr/lib/systemd/system-sleep/` with the following contents:

    /usr/lib/systemd/system-sleep/00powersave

    #!/bin/sh

    case $1 in
        pre) /path/to/your/script false ;;
        post)
    	if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1
    	then
        		/path/to/your/script true
    	else
        		/path/to/your/script false
    	fi
        ;;
    esac
    exit 0

Do not forget to make it executable!

Note: Be aware that AC0 may be different for your laptop, change it if that is the case.

### Print power settings

This article or section is a candidate for merging with #Power saving.

Notes: Might be good as an introduction? Since most of the output of the script can be used by the following sections. (Discuss in Talk:Power management)

This script prints power settings and a variety of other properties for USB and PCI devices. Note that root permissions are needed to see all settings.

    #!/bin/bash

    for i in $(find /sys/devices -name "bMaxPower")
    do
    	busdir=${i%/*}
    	busnum=$(<$busdir/busnum)
    	devnum=$(<$busdir/devnum)
    	title=$(lsusb -s $busnum:$devnum)

    	printf "\n\n+++ %s\n  -%s\n" "$title" "$busdir"

    	for ff in $(find $busdir/power -type f ! -empty 2>/dev/null)
    	do
    		v=$(cat $ff 2>/dev/null|tr -d "\n")
    		[[ ${#v} -gt 0 ]] && echo -e " ${ff##*/}=$v";
    		v=;
    	done | sort -g;
    done;

    printf "\n\n\n+++ %s\n" "Kernel Modules"
    for mod in $(lspci -k | sed -n '/in use:/s,^.*: ,,p' | sort -u)
    do
    	echo "+ $mod";
    	systool -v -m $mod 2> /dev/null | sed -n "/Parameters:/,/^$/p";
    done

## Allow users to shutdown

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: Merged from Allow users to shutdown, needs reorganization to fit into this page. (Discuss in Talk:Power management)

### Button and lid events

The suspend, poweroff and hibernate button presses and lid close events are handled by logind as described in #ACPI events.

### Using systemd-logind

If you are using polkit, users with non-remote session can issue power-related commands as long as the session is not broken.

To check if your session is active

    $ loginctl show-session $XDG_SESSION_ID --property=Active

The user can then use systemctl commands in the command line, or add them to menus:

    $ systemctl poweroff
    $ systemctl reboot

Other commands can be used as well, including `systemctl suspend` and `systemctl hibernate`. See the System Commands section in systemctl(1).

### Using sudo

Install sudo, and give the user sudo privileges. The user will then be able to use the `sudo systemctl` commands (e.g. `sudo systemctl poweroff`, `sudo systemctl reboot`, `sudo systemctl suspend` and `sudo systemctl hibernate`). See the System Commands section in systemctl(1)

#### Users without sudo privileges

If users should only be allowed to use shutdown commands, but not have other sudo privileges, then, as root, add the following to the end of `/etc/sudoers` using the `visudo` command. Substitute user for your username and hostname for the machine's hostname.

    user hostname =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot

Now your user can shutdown with `sudo systemctl poweroff`, and reboot with `sudo systemctl reboot`. Users wishing to power down a system can also use `sudo systemctl halt`. Use the `NOPASSWD:` tag only if you do not want to be prompted for your password.

## See also

- ThinkWiki:How to reduce power consumption
- How to get longer battery life on Linux

Category:

- Power management

Hidden categories:

- Pages or sections flagged with Template:Accuracy
- Pages or sections flagged with Template:Merge
- Pages or sections flagged with Template:Expansion
- Pages or sections flagged with Template:Out of date
- Pages or sections flagged with Template:Style