[TRACKING] Linux battery life tuning

Linen · March 10, 2022, 1:43pm

How would I be able to disable intel_pstate? Thanks!

Animesh_Sahu · March 11, 2022, 7:47am

Add intel_pstate=disable to GRUB_CMDLINE_LINUX_DEFAULT= at /etc/default/grub.

theraser · March 11, 2022, 7:59am

I tried to post an answer to @Philipp_D here yesterday, but always got a “403 Forbidden”. I’m not sure if this is due to the content, so here is a new try…

Please try to run powertop using “–debug”, maybe this can help us.

Philipp_D · March 11, 2022, 8:11am

@theraser Ohhh it has such a flag? Neat! I was not aware!
The output of that statement is pretty much a very often repeating:

Best parameter is 111
Changing score from 33321.750 to 33321.750
Changing value from 0.000 to 0.100
Retry is 85
delta is 0.0090
Best parameter is 2
Changing score from 33321.750 to 33321.692
Changing value from 0.641 to 0.636
Retry is 84
delta is 0.0090
Best parameter is 24
Changing score from 33321.692 to 33321.508
Changing value from 0.610 to 0.615
Retry is 82

The “Retry is” line counts down to 0 eventually and then starts over until this is output is reached:

Best parameter is 78
Changing score from 33172.151 to 33172.151
Changing value from 0.100 to 0.100
Final score 44.23 (750 points)

Parameter state

Value Name
0.46 alsa-codec-power (2)
2.82 backlight (3)
0.00 backlight-boost-100 (4)
0.00 backlight-boost-40 (5)
0.00 backlight-boost-80 (6)
4.51 backlight-power (7)
9.92 base power (8)
0.00 br-b74753b7788e-link-100 (9)
0.00 br-b74753b7788e-link-1000 (10)
0.00 br-b74753b7788e-link-high (11)
0.00 br-b74753b7788e-packets (12)
0.00 br-b74753b7788e-powerunsave (13)
0.00 br-b74753b7788e-up (14)
1.80 cpu-consumption (15)
23.76 cpu-wakeups (16)
0.00 disk-operations (17)
0.00 disk-operations-hard (18)
0.00 docker0-link-100 (19)
0.00 docker0-link-1000 (20)
0.00 docker0-link-high (21)
0.00 docker0-packets (22)
0.00 docker0-powerunsave (23)
1.04 docker0-up (24)
0.00 gpu-operations (25)
0.00 radio:hci0 (26)
0.00 radio:phy0 (27)
0.00 runtime-0000:00:00.0 (28)
0.00 runtime-0000:00:02.0 (29)
0.00 runtime-0000:00:04.0 (30)
0.00 runtime-0000:00:06.0 (31)
0.00 runtime-0000:00:07.0 (32)
0.00 runtime-0000:00:07.1 (33)
0.00 runtime-0000:00:07.2 (34)
0.00 runtime-0000:00:07.3 (35)
0.00 runtime-0000:00:08.0 (36)
0.00 runtime-0000:00:0a.0 (37)
0.00 runtime-0000:00:0d.0 (38)
0.00 runtime-0000:00:0d.2 (39)
0.00 runtime-0000:00:0d.3 (40)
0.00 runtime-0000:00:12.0 (41)
0.00 runtime-0000:00:14.0 (42)
0.00 runtime-0000:00:14.2 (43)
0.00 runtime-0000:00:15.0 (44)
0.00 runtime-0000:00:15.1 (45)
0.00 runtime-0000:00:15.3 (46)
0.00 runtime-0000:00:16.0 (47)
0.00 runtime-0000:00:1d.0 (48)
0.00 runtime-0000:00:1f.0 (49)
0.00 runtime-0000:00:1f.3 (50)
0.00 runtime-0000:00:1f.4 (51)
0.00 runtime-0000:00:1f.5 (52)
0.00 runtime-0000:01:00.0 (53)
0.00 runtime-0000:aa:00.0 (54)
0.00 runtime-17-0036 (55)
0.00 runtime-17-0037 (56)
0.00 runtime-17-0050 (57)
0.00 runtime-ACPI0003:00 (58)
0.00 runtime-ACPI000C:00 (59)
0.00 runtime-HID-SENSOR-200001.2.auto (60)
0.00 runtime-HID-SENSOR-200041.4.auto (61)
0.00 runtime-HID-SENSOR-2000e1.3.auto (62)
0.00 runtime-INT33A1:00 (63)
0.00 runtime-INT34C5:00 (64)
0.00 runtime-INTC1040:00 (65)
0.00 runtime-INTC1043:00 (66)
0.00 runtime-INTC1043:01 (67)
0.00 runtime-NTC0702:00 (68)
0.00 runtime-PNP0C09:00 (69)
0.00 runtime-PNP0C0A:00 (70)
0.00 runtime-PNP0C0C:00 (71)
0.00 runtime-PNP0C0D:00 (72)
0.00 runtime-PNP0C14:00 (73)
0.00 runtime-PNP0C14:01 (74)
0.00 runtime-USBC000:00 (75)
0.00 runtime-alarmtimer.0.auto (76)
0.00 runtime-coretemp.0 (77)
0.00 runtime-efi-framebuffer.0 (78)
0.00 runtime-efivars.0 (79)
0.00 runtime-i2c-0 (80)
0.00 runtime-i2c-1 (81)
0.00 runtime-i2c-10 (82)
0.00 runtime-i2c-11 (83)
0.00 runtime-i2c-12 (84)
0.00 runtime-i2c-13 (85)
0.00 runtime-i2c-14 (86)
0.00 runtime-i2c-15 (87)
0.00 runtime-i2c-16 (88)
0.00 runtime-i2c-17 (89)
0.00 runtime-i2c-2 (90)
0.00 runtime-i2c-3 (91)
0.00 runtime-i2c-4 (92)
0.00 runtime-i2c-5 (93)
0.00 runtime-i2c-6 (94)
0.00 runtime-i2c-7 (95)
0.00 runtime-i2c-8 (96)
0.00 runtime-i2c-9 (97)
0.00 runtime-i2c-FRMW0001:00 (98)
0.00 runtime-i2c-PIXA3854:00 (99)
0.00 runtime-i2c-SONY488A:00 (100)
0.00 runtime-i2c_designware.0 (101)
0.00 runtime-i2c_designware.1 (102)
0.00 runtime-i2c_designware.2 (103)
0.00 runtime-i8042 (104)
0.00 runtime-iTCO_wdt (105)
0.00 runtime-idma64.0 (106)
0.00 runtime-idma64.1 (107)
0.00 runtime-idma64.2 (108)
0.00 runtime-intel_rapl_msr.0 (109)
0.00 runtime-microcode (110)
0.00 runtime-pcspkr (111)
0.00 runtime-pmt_telemetry.1.auto (112)
0.00 runtime-reg-dummy (113)
0.00 runtime-regulatory.0 (114)
0.00 runtime-rtc-efi.0 (115)
0.00 runtime-rtc_cmos (116)
0.00 runtime-serial8250 (117)
0.00 runtime-snd-soc-dummy (118)
0.00 usb-device-1d6b-0002 (119)
0.00 usb-device-1d6b-0003 (120)
0.00 usb-device-27c6-609c (121)
1.22 usb-device-32ac-0002 (122)
0.00 usb-device-8087-0032 (123)
0.00 wlan0-link-100 (124)
0.00 wlan0-link-1000 (125)
0.00 wlan0-link-high (126)
0.00 wlan0-packets (127)
0.00 wlan0-powerunsave (128)
0.00 wlan0-up (129)
0.00 xwakes (130)

Score: 2.6 (33172.2)
Guess: 9.9
Actual: 6.5

theraser · March 11, 2022, 8:53am

This looks pretty good, powertop seems to be working without problems

Using Arch myself powertop needs a few seconds to start, what happens if you run it without --debug and wait? If it just hangs forever, maybe reinstalling helps. But this topic may be better discussed at the Arch Linux Forum as this likely is a software error and has nothing to do with the Framework Laptop.

technical27 · March 11, 2022, 6:08pm

I was having trouble hitting PC10, but then I found out it works after a reboot/fresh boot but not after suspending. It always works during suspend, but after the first suspend, it no longer worked in normal use until the next power cycle.

I spent some time investigating and turns out this code is responsible for that

github.com

torvalds/linux/blob/cb323ee75d24e7acc2f188d123ba6df46159cf09/drivers/nvme/host/pci.c#L3095

      
        
            		goto unmap;
            
            
	quirks |= check_vendor_combination_bug(pdev);
            
            
	if (!noacpi && acpi_storage_d3(&pdev->dev)) {
            		/*
            		 * Some systems use a bios work around to ask for D3 on
            		 * platforms that support kernel managed suspend.
            		 */
            		dev_info(&pdev->dev,
            			 "platform quirk: setting simple suspend\n");
            		quirks |= NVME_QUIRK_SIMPLE_SUSPEND;
            	}
            
            
	/*
            	 * Double check that our mempool alloc size will cover the biggest
            	 * command we support.
            	 */
            	alloc_size = nvme_pci_iod_alloc_size();
            	WARN_ON_ONCE(alloc_size > PAGE_SIZE);

The fix, add nvme.noacpi=1 to your kernel parameters.
PC10 now works after suspending and power usage while under light use should improve.

MarkB · March 13, 2022, 4:36pm

Excellent catch! I knew that I had hit C10 once or twice in the past, but couldn’t seem to replicate those results reliably. This explains it.

For those who need it spelled out more: I verified the fix by following these steps:

Reboot
Verify hitting C10 with powertop
Suspend, then re-awaken
Verify not hitting C10

I then added nvme.noacpi=1 to GRUB_CMDLINE_LINUX_DEFAULT (see here for how to do that) and repeated the procedure above. After the change, step (4) shows that I’m getting to C10 even after a suspend.

I’m using

Manjaro Linux
Kernel 5.15.25-1-MANJARO
TLP for power management (all default settings, for now)

MarkB · March 13, 2022, 7:01pm

Well, almost.

It seems that running Firefox also seems to keep me from getting to C10. With powertop running and Firefox open, I never drop below C8, but I see an immediate drop to C10 when I quit Firefox. I do tend to have a fair number of tabs open, but nothing animated until I start watching YouTube or Netflix, etc. I do have Gmail and Google Calendar in pinned tabs, but nothing else that would be actively repainting themselves. (And they’re certainly not on the screen all the time.)

EDIT: Starting Firefox with a new profile still allows dropping to C10, so it’s clearly something I’m doing within Firefox that keeps me running hotter.

theraser · March 13, 2022, 10:13pm

I cannot reproduce this error Which suspend mode are you using? You can check this using cat /sys/power/mem_sleep.

I’m using Arch with latest kernel 5.16.14-arch1-1 and “deep” suspend mode. No problems after suspending multiple times here. If you continue to hit this error, you may want to open a bug report at your Linux distribution for this. Maybe there is something going wrong at kernel level which can be fixed. And since @technical27 already found a workaround and the code snippet, chances are good to get this fixed.

PhilS · April 8, 2022, 7:20pm

I can confirm installing PipeWire to replace PulseAudio dropped my idle power around a watt! Definitely worth doing. I am running Ubuntu 20.04 with Kernel 5.14.9. I followed this guide:

If you are on 21.04, this might be a better choice (no need for the PPA):

mhvk · April 17, 2022, 9:16pm

Great summary! It may be good to add the warning that after resuming from suspend to s2idle, power consumption is way higher because only power states down to C3 are used (see Issues with power usage - #5 by Brad_J). This would seem a straight-up bug (not sure it is the kernel or bios). After a deep suspend, things are back to normal. But resuming from deep suspend takes rather long (also a bug?).

Maybe useful for others, my measurements with powertop (i7, 32GB, 3.07 bios; Debian/KDE,X11,pipewire, konsole only, radios off (flight mode), removed HDMI extension card

screen at 5%: 2.0 W, CPU 95% in C10
screen at 50%: 3.1 W
screen at 100%: 4.3 W
screen at 5%, insert HMDI: 2.9 W
- after autosuspend HDMI: 2.4 W
screen at 5%, HDMI removed, radios on: 2.2 W (connected or not makes little difference)
after s2idle suspend, radios off: 4.4 W; EDIT: this is solved with nvme.noacpi=1 - see Linux battery life tuning - #156 by technical27
after deep suspend: 2.0 W

Overall, idle power of ~2W (presumably, window manager turns screen off; ~2.4W at 100%) seems very reasonable! But concrete things/bug fixes that would make it generally happen are:

Ensure regular state after s2idle resume (and, it sounds like, make s2idle better!); EDIT: regular state can be ensured - see Linux battery life tuning - #156 by technical27
Ensure HDMI dongle uses less power (beyond what is gained from suspending it)
Somehow make resume from deep suspend faster?

p.s. For reference, my old X1 Yoga 2nd gen also has an idle power consumption of ~2W.

lightrush · April 18, 2022, 4:15am

Just reproduced this and I was a bit baffled. I haven’t previously come across a description of this bug and never noticed it myself. It adds ~2.5W of idle power burn on mine. Has anyone done research on whether this is a hardware/firmware or kernel bug?

lbkNhubert · April 18, 2022, 4:42am

@lightrush, this post from further up in this thread may help: Linux battery life tuning - #156 by technical27

lightrush · April 18, 2022, 4:58am

@lbkNhubert confirmed, it does resolve the problem. I’ll add that to the Ubuntu post-install formula even though most people using it probably have deep sleep as that’s the default. I actually use s2idle with suspend-then-hibernate so I’m affected. Thanks for the sleuth work @technical27 !

Edit: Aaand done. Whoever’s using this will automagically get the workaround applied.

nrp · April 18, 2022, 7:06am

Confirmed as well here on noacpi=1 reducing s2idle power draw. We’re checking why that is.

mhvk · April 18, 2022, 7:32pm

@TJ1 - the information from Linux battery life tuning - #156 by technical27 would seem worth adding to your suspend section on top! Thanks so much, @technical27!

robert_b · April 19, 2022, 5:48pm

Hi all,

I noticed a rather high power drain by the USB-A extension card.

My system: i7-1165G7, 64GB RAM 3200Mhz, Samsung 980 PRO 1TB. ArchLinux (kernel 5.17.3).

My settings: TLP default settings, no extension cards plugged, radios off, backlight 1%

With this I get ~2W idle power usage (according to powertop). However, as soon as I plug in a USB-A extension card, the power consumption increases by ~300-400mw for each USB-A card (tried with two cards). USB-C extension cards did not affect the power consumption.

Did anyone else experience this?

Regards,

Robert

mhvk · April 19, 2022, 8:57pm

@robert_b - I thought USB A was better than HDMI, but I just checked and confirmed that the USB A dongle takes about 300 mW. Without my HDMI and USBA, with radios off and 5% display, I got about 1.7 W idle (after waiting quite a while).

D.H · April 20, 2022, 11:17am

It’s been mentioned quite a few times in this thread, and elsewhere in this forum.

Here’s the best explanation I’ve seen as to why: Switchable USB-A and HDMI adapters - #9 by Luke_Mahowald

BIOS 3.08 is supposedly going to address battery drain during shutdown and possibly hibernate and standby. I wonder if they can address the drain of keeping usb-a’s ready to accept a device using the same methods.

Good news about framework is you have the option of the removing the cards you don’t need to eke out a bit more autonomy, unlike other laptops…