Howto: Powersaving tweaks with a udev rule


Recommended Posts

I previously made a guide showing how you can utilize pm-utils scripts to enable extra powersaving settings in linux: http://www.neowin.ne...-with-pm-utils/.

I've since found a solution I like better, because its much simpler and I am also trying to lessen my dependence on pm-utils (it seems there's been no active development for the past few years). I'm hoping I'll be able to uninstall it eventually since the latest upower can now use systemd instead of pm-utils for suspend/hibernate, but it still seems to require pm-utils for some things.

Anyway, on to the guide. I found this solution over on the arch forums: https://bbs.archlinu...163335#p1163335.

Basically all this solution is: A udev rule that detects whether your system is on AC or Battery, then runs a script, and passes a true or false value to the script depending on whether you are on AC or Battery.

1. Create the udev rule. Create a file named /etc/udev/rules.d/50-powersave.rules. Place the following in the file:


SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/usr/bin/powersave true"
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/usr/bin/powersave false"
[/CODE]

In this example my powersaving script is located at /usr/bin/powersave. If you want your script in a different location, make sure to change the path there.

2. Create the powersaving script. I've saved my script at /usr/bin/powersave. Here is an example script, this is the one I use on my system. With this type of thing your mileage will vary, you may have to use different commands depending on your hardware and/or preferences. My example script is fairly conservative and should work fine for most:

[CODE]
#!/bin/sh
case "$1" in
true) # Enable power saving settings on battery
# Device Runtime-PM
for dpcontrol in /sys/bus/{pci,spi,i2c}/devices/*/power/control; do echo auto > $dpcontrol; done
# Disable nmi_watchdog
echo 0 > /proc/sys/kernel/nmi_watchdog
# kernel write mode
echo 5 > /proc/sys/vm/laptop_mode
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
# disk powersave
hdparm -S 36 -B 128 /dev/sda &> /dev/null
for i in /sys/class/scsi_host/host*/link_power_management_policy; do echo min_power > $i; done
# sound card powersave
echo 10 > /sys/module/snd_hda_intel/parameters/power_save
echo Y > /sys/module/snd_hda_intel/parameters/power_save_controller
# wlan0 powersave
iw dev wlan0 set power_save on &> /dev/null
;;
false) # Return to default on AC power
# Device Runtime-PM
for dpcontrol in /sys/bus/{pci,spi,i2c}/devices/*/power/control; do echo on > $dpcontrol; done
# Enable nmi_watchdog
echo 1 > /proc/sys/kernel/nmi_watchdog
# kernel write mode
echo 0 > /proc/sys/vm/laptop_mode
echo 500 > /proc/sys/vm/dirty_writeback_centisecs
# disk powersave
hdparm -S 0 -B 254 /dev/sda &> /dev/null
for i in /sys/class/scsi_host/host*/link_power_management_policy; do echo max_performance > $i; done
# sound card powersave
echo 300 > /sys/module/snd_hda_intel/parameters/power_save
echo Y > /sys/module/snd_hda_intel/parameters/power_save_controller
# wlan0 powersave
iw dev wlan0 set power_save off &> /dev/null
;;
esac
exit 0
[/CODE]

3. Then you just make the powersave script executable, and run [b]udevadm control --reload-rules[/b] to make udev recognize the rule we added.

4. Tweak the script to your liking! Below I've explained what the commands in the example do, and some possible things to try out and/or look out for:

[b]Runtime-PM:[/b] [size=4][font=arial,helvetica,sans-serif]The first command in the script enables runtime-pm for everything except USB devices (since the kernel does it automatically on my machine, as I explain in the USB autosuspend section. In addition my system requires USB modules to be unloaded before suspend or else it hangs, and I do this via a systemd sleep hook. If I mess with toggling usb powersaving settings on my machine, the values get set inconsistently after suspend/resume). The command to enable runtime-pm for all devices on your machine would be:[/font][/size] [color=#333333][font=Consolas,][b]for i in /sys/bus/*/devices/*/power/control; do echo auto > $i; done[/b]. [font=arial,helvetica,sans-serif][size=4]You can echo "on" instead of auto if you want to disable it on AC. If you don't have bugs like my machine has the above command should work fine :)[/size][/font][/font][/color]

[color=#333333][font=Consolas,][font=arial,helvetica,sans-serif][size=4][b]NMI Watchdog:[/b] This is safe to disable, disabling it saves a bit of battery life.[/size][/font][/font][/color]

[color=#333333][font=Consolas,][font=arial,helvetica,sans-serif][size=4][b]VM Writeback:[/b] Increasing the vm_writeback value on battery causes less disk writes and can save a bit of power (and can help allow the disk to spindown). The value in my example script is the one recommended by powertop and is safe. [/size][/font][/font][/color]

[b]USB autosuspend:[/b] I don't have any usb autosuspend settings in my script, because the newest kernels seem to enable this automatically (on my arch system, even with no powersaving tweaks via pm-utils or this method, usb autosuspend is enabled by default with a 2 second timeout). If you need to enable it manually, you could use these commands:

[CODE]
# usb autosuspend

for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done
for i in /sys/bus/usb/devices/*/power/level; do echo auto > $i; done
[/CODE]

The first command sets the timeout of how many seconds to wait to suspend usb devices after they've been idle, this example uses 1 second. The second command enables usb autosuspend. To disable USB autosuspend you would echo "0" and "on" instead of "1" and "auto".

[b]HDparm Settings: [/b]My script uses pretty conservative hdparm settings that shouldn't spin down your drive like crazy. I use hdparm -S 36 to set the disk spindown timeout to 3 minutes, and hdparm -B 128 which is the most conservative value that still allows disk spindown. If you don't want to use disk spindown at all use [b][color=#333333]hdparm -S 0 -B 254 /dev/sda &> /dev/null[/color][/b] instead.

[b]Sata Link Power Management: [/b]sata aplm is known to be buggy on certain hardware (potentially causing data loss) so only enable this option if you know it works on your machine. To disable it comment out the [color=#333333][font=Consolas,][b]link_power_management_policy[/b] [size=4]line.[/size][/font][/color]

[b]Intel Audio Powersave:[/b] My script enables intel audio powersave on both battery and AC, but with a 5 minute timeout on AC, and 10 seconds on battery. I have intel controller powersave enabled on both AC and Battery due to a bug (If you toggle that one on and off then your audio codecs run at 100% all the time even when they are supposed to be in powersave). So if you want to enable this option this is the recommended way to do it. However enabling controller powersave can produce audible clicks when powersaving goes in and out of effect. If this annoys you, try increasing the timeout values or disabling controller powersave on both ac and battery (by echoing N instead of Y)

[b]Wireless:[/b] Mileage may vary on this one, it depends on the wireless tools your distro uses. My example uses the iw tool to enable wireless powersaving, other distros may use iwconfig. If you need to use iwconfig the command would be:[b] [color=#333333]iwconfig wlan0 power on &> /dev/null[/color][/b]

[b]Screen Brightness: [/b]Gnome does this for me, so there is no screen brightness settings in my script. If you wanted to add this an example would be:

To lower brightness and enable display power management on battery:

[CODE]
for i in /sys/class/backlight/acpi_video*/brightness; do echo 0 > $i; done

xset +dpms
xset dpms 0 0 120
[/CODE]

To restore brightness and disable dpms:

[CODE]
for i in /sys/class/backlight/acpi_video*/brightness; do echo 9 > $i; done

xset -dpms
[/CODE]

Remember you want to put any settings you want enabled on battery under the "True" section of the script, and settings you want on AC in the "false" section.

I have only tested this method in arch, but see no reason why it wouldn't work in other distros.

  • 2 months later...
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Glad these prices are starting to come down, but that is still crazy. I bought the 2TB 9100 Pro (slightly more expensive version with PCIe 5.0) last year for $240.
    • The 2TB Samsung 990 PRO NVMe SSD hits lowest price in over three months by Sayan Sen Yesterday, we covered a really good deal wherein you can get a 4TB TeamGroup T-FORCE G50 NVMe PCIe Gen4 SSD for a low price of just $400 with a special discount coupon. That's just $100 per TB, making it a very good offer during these hard times. The deal is still live, so you can check it out in its dedicated article here if you do not want to miss out. Meanwhile, if you don't have that kind of budget but still wish to buy an SSD for a good price, the 2TB variant of the TeamGroup SSD at $280 its lowest price in over three months. Meanwhile, those seeking 2TB but faster performance can check out Samsung's 990 PRO, which has hit the lowest price also in the last quarter or so, as it's on sale for $370 (purchase links under the specs table down below). Thus, you want a faster drive, get the 990 Pro, or you want more capacity, grab the TeamGroup 4TB linked in the first para. The 990 PRO is a PCIe Gen4 NVMe SSD and still one of the fastest drives available today for under $500. Speaking of fast, sequential reads and writes are rated at 7450 MB/s and 6900 MB/s, respectively. The random throughputs for reads and writes are 1400K IOPS and 1550K IOPS, respectively. The 990 PRO is based on Samsung's 7th Gen V-NAND flash, and it too is TLC. It packs 2 gigs of LPDDR4 DRAM cache, which helps the random performance. The endurance rating for this is 1200 TBW (terabytes written), which should be sufficient for most users. The Samsung 990 PRO is compatible with the PlayStation 5, but if you are going to use the 990 PRO on a PC, check out the Samsung Magician app that lets you track your drive's health, update its firmware, customize various settings, and more. The tech specs are given below: Specification TeamGroup T-FORCE G50 2TB Samsung 990 PRO 2TB Interface PCIe 4.0 x4, NVMe 1.4 PCIe Gen 4.0 x4, NVMe 2.0 Form Factor M.2 2280 M.2 2280 Controller InnoGrit Controller Samsung In-house Controller NAND Flash 3D TLC 3D TLC DRAM Cache None (HMB supported) 2GB LPDDR4 Sequential Read (Max) 5,000 MB/s 7,450 MB/s Sequential Write (Max) 4,500 MB/s 6,900 MB/s Random Read (4K) Up to 600,000 IOPS Up to 1,400,000 IOPS Random Write (4K) Up to 700,000 IOPS Up to 1,550,000 IOPS TBW (Endurance) 1,300 TBW 1,200 TBW MTBF 3,000,000 hours 1,500,000 hours Operating Temperature 0°C to 70°C 0°C to 70°C Storage Temperature -40°C to 85°C -40°C to 85°C Shock Resistance 1,500G / 0.5ms 1,500G / 0.5ms Heatsink Patented Graphene Heat Spreader No Get them at the links below: Samsung 990 PRO SSD 2TB (MZ-V9P2T0B/AM): $369.99 (Sold and Shipped by Amazon US) TEAMGROUP T-Force G50 2TB SSD (TM8FFE002T0C129): $279.99 (Sold by TeamGroup, Shipped by Amazon US) Good to know This Amazon deal is U.S. specific, and not available in other regions unless specified. We only use first-party seller links (at the time of article publishing); ensure that you purchase from a first-party seller link only. Check out Today's Deals on Amazon | or our recent tech deals. Become a Prime member (for Students or SNAP) via Neowin Get Prime Access - Prime for half price (for qualifying Medicaid, EBT, SNAP) Subscribe to Prime Video, Audible Plus, Music Unlimited or Kindle Unlimited via Neowin As an Amazon Associate, we earn from qualifying purchases.
    • If you can't spell a simple word that 2nd graders learn, your entire argument is suspect.
    • And here goes the "Won't someone think of the children" brigade. Get stuffed mate. This has NOTHING to do with making the internet safe. It's about tracking adults, spying on your online activity, and sending the boys around when they don't like something you post. Also, again, parliament have voted TWICE against this, and Starmer is going ahead anyway. THAT is anti-democratic bullsh**. They will use this law to track you, they will use this law to control you, and they will use this law to punish you if they don't like what you do, even if it's legal. And your data? Say bye bye to that. It'll be on the darkweb in weeks. I'm not some rando online. I've been an IT professional for 40 years, many of it in security. I know exactly what this means and what will happen to your data. I do not consent and I will not comply.
    • "...but it may not be Microsoft's fault" seems like a reasonable way to tease what is going on without leaving the user with a false impression that an update is the problem. A title isn't a summery, it is meant to entice the user to read the article. It should not contain a misleading premise; which this title does not. You could maybe complain that the first paragraph should have included that detail. The writing style popularized over 100 years ago in newspapers will cover the most important information as soon as possible with details and nuance added later; the idea being that with each new paragraph you have less of the reader's focus.
  • Recent Achievements

    • First Post
      Jocimo earned a badge
      First Post
    • Week One Done
      suprememobiles48 earned a badge
      Week One Done
    • One Month Later
      Windows Guy earned a badge
      One Month Later
    • One Month Later
      Prasann earned a badge
      One Month Later
    • Week One Done
      Prasann earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      520
    2. 2
      +Edouard
      174
    3. 3
      PsYcHoKiLLa
      90
    4. 4
      Steven P.
      81
    5. 5
      ATLien_0
      70
  • Tell a friend

    Love Neowin? Tell a friend!