[TRACKING] Linux battery life tuning

Well you do seem to be casually running teams in the background and calling it idle sometimes XD

My setup is arch on kernel 6.6 running sway. I did also switch to an ax210 instead of the mediatek but I never got around to doing proper a/b testing on that part.

I left that on

Wrt Decode usage - do you get differences between mesa git repo?

https://copr.fedorainfracloud.org/coprs/xxmitsu/mesa-git/

Probably why I see a huge difference between the two. The machine is still ridiculously responsive and fast on battery for the work loads I am performing on battery. So the slight performance hit is something I am willing to live with while on battery since it is barely noticeable to me.

1 Like

In what scenarios did you see significant differences?

I am not going to go into exhaustive detail as to what my setup is and what I am doing as it has been posted multiple times in this thread alone. Suffice to say when on battery PPD would be lucky to get down into the high 6.90+ range as the lowest it would go and it would take some time getting there, with TLP with turbo off on battery I get down to 4.53w regularly and qucikly. TLP idled quicker and hasin field testing lasted me up to 2 hours longer than PPD.

I am running Fedora 39 Workstation on a 12th gen Intel i7-1260p FW13, 64GB RAM, 2TB SKHynix P41 nvme, all usb-c modules, matte display at 30%, with firefox, evolution, terminal, and quod libet running via headset, buetooth is off. I regularly get 9+ hours out of it on battery with TLP, with PPD as low as 6 hours without changing my usage pattern or behavior.

1 Like

Hi, a critical use case for me is being able to work for a full day without mains. First setting up my FW13, it seemed like it wasn’t going to be possible, however with a little tuning, things are looking much better.

As @jwp noted here and in the above posted thread, there are still some kernel fixups for amd pstate in process.

I’ve run some preliminary benchmarks via PTS and so far am seeing strong cpu/gpu performance. I’ll post results as I have more.

In your shoes, I would
a) install and run powertop to see what’s draining your battery
b) config my system as detailed in the above thread or at very least with:
PPD set to power-saver, EPP set to power (or balance_power), USB autosuspend enabled
c) run some tests for 10% battery or more to evaluate energy draw
d) for perforumance, move to at least balance_power EPP, run benchmarks of interest to you (bound to cpu, gpu or both)
e) make an informed decision about whether the FW13 fits your needs or not

Hope this helps!

3 Likes

Hey @jwp, I have 6.7.0-rc3 with the perfcore patch set on Arch Linux but still seeing ~5w idle power consumption (with screen on but at min brightness)…

Time    User  Nice   Sys  Idle    IO  Run Ctxt/s  IRQ/s Fork Exec Exit  Watts   CPU Freq  Freq Min  Freq Max
01:10:29   0.2   0.0   0.2  99.6   0.0    1    720    594    9    2    4   5.44   0.63 GHz  0.40 GHz  2.17 GHz
01:10:39   0.2   0.0   0.1  99.7   0.0    1    691    555    2    0    7   5.37   0.62 GHz  0.40 GHz  2.07 GHz
01:10:49   0.1   0.0   0.1  99.7   0.0    1    662    523    0    0    0   5.31   0.44 GHz  0.40 GHz  1.40 GHz
01:10:59   0.1   0.0   0.2  99.7   0.0    1    623    494    0    0    0   5.31   0.72 GHz  0.40 GHz  2.28 GHz
01:11:09   0.2   0.0   0.2  99.6   0.0    1    749    598    0    0    0   5.32   0.40 GHz  0.40 GHz  0.40 GHz
01:11:19   0.2   0.0   0.2  99.6   0.0    1    667    530    0    0    0   5.31   0.49 GHz  0.40 GHz  1.40 GHz
01:11:29   0.2   0.0   0.2  99.6   0.0    1    659    518    0    0    0   5.31   0.40 GHz  0.40 GHz  0.40 GHz
01:11:39   0.1   0.0   0.1  99.8   0.0    1    487    382    0    0    0   5.25   0.40 GHz  0.40 GHz  0.40 GHz
01:11:49   0.2   0.0   0.1  99.7   0.0    1    588    464    0    0    0   5.27   0.73 GHz  0.40 GHz  2.28 GHz
01:11:59   0.2   0.0   0.2  99.6   0.0    1    701    691    9    2    3   5.23   1.05 GHz  0.40 GHz  2.28 GHz
01:12:09   0.2   0.0   0.2  99.7   0.0    1    710    597    2    0    8   5.37   0.40 GHz  0.40 GHz  0.40 GHz
01:12:19   0.1   0.0   0.1  99.8   0.0    1    608    493    0    0    0   5.39   0.45 GHz  0.40 GHz  1.45 GHz
01:12:29   0.1   0.0   0.1  99.7   0.0    1    559    435    0    0    0   5.37   0.40 GHz  0.40 GHz  0.40 GHz
01:12:39   0.4   0.0   0.5  99.1   0.0    1   1510   1966   66   30   60   5.65   0.40 GHz  0.40 GHz  0.40 GHz
01:12:49   0.4   0.0   0.5  99.1   0.0    1   1472   2213    0    0    0   5.88   0.55 GHz  0.40 GHz  1.40 GHz
01:12:59   0.3   0.0   0.5  99.2   0.0    1   1441   1729   23    7   23   5.88   0.90 GHz  0.40 GHz  2.13 GHz
01:13:09   0.2   0.0   0.4  99.5   0.0    1    650    522    0    0    0   5.67   0.87 GHz  0.40 GHz  1.99 GHz
01:13:19   0.2   0.0   0.3  99.5   0.0    1    559    463    0    0    0   5.59   0.69 GHz  0.40 GHz  1.81 GHz
01:13:29   0.2   0.0   0.4  99.4   0.0    1    692    570    0    0    1   5.55   0.44 GHz  0.40 GHz  1.40 GHz
01:13:39   0.2   0.0   0.4  99.5   0.0    1    580    482    1    0    0   5.49   0.40 GHz  0.40 GHz  0.40 GHz
01:13:49   0.2   0.0   0.4  99.5   0.0    1    578    484    0    0    0   5.46   0.45 GHz  0.40 GHz  1.53 GHz
01:13:59   0.2   0.0   0.3  99.5   0.0    1    570    459    0    0    1   5.45   0.49 GHz  0.40 GHz  1.40 GHz
01:14:09   0.1   0.0   0.4  99.5   0.0    1    552    456    0    0    0   5.41   0.49 GHz  0.40 GHz  1.37 GHz
01:14:19   0.1   0.0   0.3  99.5   0.0    1    642    520    0    0    0   5.43   0.54 GHz  0.40 GHz  1.37 GHz
01:14:29   0.2   0.0   0.4  99.5   0.0    1    600    474    0    0    0   5.40   0.67 GHz  0.40 GHz  1.40 GHz
01:14:39   0.2   0.0   0.3  99.5   0.0    1    545    452    0    0    0   5.40   0.45 GHz  0.40 GHz  1.52 GHz
01:14:49   0.2   0.0   0.3  99.5   0.0    1    658    535    0    0    0   5.42   0.49 GHz  0.40 GHz  1.40 GHz
01:14:59   0.3   0.0   0.4  99.3   0.0    1    849    682   10    2    4   5.49   0.49 GHz  0.40 GHz  1.40 GHz
01:15:09   0.2   0.0   0.4  99.5   0.0    1    628    518    3    0    7   5.51   0.60 GHz  0.40 GHz  1.40 GHz
01:15:19   0.3   0.0   0.4  99.4   0.0    1    941    697    0    0    2   5.56   0.51 GHz  0.40 GHz  2.00 GHz

[root@framework amd_pstate]# cat /sys/devices/system/cpu/amd_pstate/prefcore 
enabled

Do i need any more tlp/sysfs tweaks to get it down to ~3-4W?

Use the patched version of PPD to set multi profiles (epp and platform hints) and/or use another methods to switch them (only ever should have power, low-power for bat, and balanced_performance, balanced for AC). Set auto suspend udev rules for pci and usb . Dim screen etc should be set using whatever userspace tool (in kde it’s powerdevil integrated with energy centre). Disable BT when on Bat (unless you use it).

I have

pcie_aspm.policy=powersupersave amdgpu.abmlevel=3 iomem=relaxed amdgpu.ppfeaturemask=0xffffffff 

as my kernel cli which does much of what TLP trys to do with userspace tuning. I have as mentioned far worse stability and performance with whatever tlp does over and above the above tunings which work fine with xdg desktop integrations through ppd mutli-driver patched.

I don’t know if the cros_ec_lpc patch is actually useful, but I am running it with all the kernels I have and it MAY expose some tunables via default userspace bits which get fiddled it may not. I haven’t investigated too much.

I also have the uip timer patches in my builds

@David_Markey ; oh do you fail to get als with 6.7-rc3 I think there is a regression in the init code for usb_sensor_als - you’ll see dmesg output grepping for als and that the iio bus device is not populated.?

this is dependent on your workload though. as a college student, my workload is generally something like: a couple of firefox tabs, neovim open in my terminal emulator, and maybe a document in libreoffice. my power draw is going to remain fairly constant over time - there is no heavy job that can be finished faster.

it’s late and i’m not very coherent right now, but i hope you understand what i mean?

Can I ask if you tried using Intel Performance and Energy Bias Hint and limiting P+E core frequency to push the frequency back into the efficiency curves?

1 Like

I use the default HWP.EPP. EPB is not set when HWP.EPP is available. This topic has a good explanation from the principal developer of TLP as to why TLP not setting EPB / Laptop Issues / Arch Linux Forums . Post #8 and #9 specifically.

The only items I change from the default are as follows:
CPU_BOOST_ON_AC=1
CPU_BOOST_ON_BAT=0
CPU_HWP_DYN_BOOST_ON_AC=1
CPU_HWP_DYN_BOOST_ON_BAT=0
USB_DENYLIST= (Device id’s related to assorted docks I use with the laptop)
USB_EXCLUDE_AUDIO=1
USB_EXCLUDE_BTUSB=1
DEVICES_TO_ENABLE_ON_AC=“bluetooth”
DEVICES_TO_DISABLE_ON_BAT=“bluetooth”
DEVICES_TO_DISABLE_ON_LAN_CONNECT=“wifi wwan”
DEVICES_TO_ENABLE_ON_LAN_DISCONNECT=“wifi”

That is all of it. I run TLP in conjunction with Thermald. I tried a lot of different methods of getting the longest battery life I could given my workloads, and a wide variety of tools. In the end TLP won out because it worked as expected all fo the time. My numbers hit idle states very quickly, my actual battery life vs estimated battery according to powertop line up very closely. Also the juice was simply not worth the squeeze when it came to further tweaking. Sure I might be able to squeeze out more but then I am looking at possibly disabling Secure Boot (yes I know secure boot is of questionable value but I tend to run my stuff at home close to what I run at work outside of the distro), or runnning with a Tainted Kernel (again another who might care, but once again, I want to keep it close to stock).

In this situation I simply drop a configuration file I have used for a very long time in place in /etc/tlp.d/ and forget about it. Done. No stability issues, no forgetting what knobs I might have twisted, no short battery run times, no noise issues, no heat complaints, it all simply works as intended with minimal effort on my part and this essentially works with any laptop I jump on or get a hold of that is less than 10 years old. In short two minutes and I am running.

1 Like

@jwp

[    5.299323] hid_sensor_als HID-SENSOR-200041.1.auto: failed to setup attributes
[    5.299328] hid_sensor_als: probe of HID-SENSOR-200041.1.auto failed with error -1

Yes getting some error alright…

Would you be able to point me at the UIP patch sets, and where could I obtain this patched version of PPD you mention?

Wow, thanks!

I have the same system as you so I wanted to tweak it and was looking for something simple.

I was looking through your posts, and from what I gathered, you didn’t bother with changing the CPU governors as it might not really make a difference? I see that TLP allows a fast time to reach idle so I thought it is fine.

Regarding CPU frequency limiting, I was reading an article stating that Intel pushes both cores out of their efficiency sweet spot as the default behavior, where the e cores get pushed to be even more inefficient than p cores. So I was wondering if adjusting them back to the sweet spot, would it be better?
Gracemont E cores below 3GHz, Golden Cove below 4 GHz.

After years of playing with this sort of stuff for fun, I came to the conclusion that letting the kernel handle stuff is usually the best thing you can do. Sure you might be able to squeak our a little extra…except it then breaks because of a change you missed…and then it is time to go on a hunt trying to figure out why your changes are not working. Also limiting freqs directly I found hampers performance to such an extent that the extended work time actually kills battery life.

3 Likes

That’s a fair point. I guess I will skip that then.

I was just thinking from the point of view similar to desktop where I limit TDP which loses like 5% performance for like 20 degrees and 20% less power. So was trying to apply it similarly here where we push it back to the efficiency curve so we lose a little performance but get much better thermals and consume less power.

Thermald basically does that. It uses DPTF by default, which essentially puts a mild throttle on the CPU … i.e. it performs the way the manufacturer designed it to perform, and under these conditions it runs very well by default. It is performant, runs reasonably cool, and mostly quiet. Turbo is the only thing that really prevents it from being a viable option on its own, because Turbo pushes the frequencies beyond the point of efficient usage for a brief extra bit of perfromance, at the cost of a lot of power. Great when you are plugged in and probably don’t care about power draw, extra heat, and extra noise.

1 Like

I just realised the base frequencies are at the range that makes them work efficiently.

Thanks for the discussion. Now all that is left is for me to get back my Framework i7-1260p laptop once my relative is done with his course.

That being said, I am kinda excited for Meteor Lake if the battery life is even better without tweaks with a much better iGPU.

1 Like

That is the buzz. I think the 15th gen is going to make Intel Mobile truly competitive again across the board. I went 12th gen instead of waiting for an AMD one because Thunderbolt was/is that important to me, and assurances that USB4 is comparable just did not cut it.

1 Like

Supposedly Meteor Lake comes with the really low power CPU cores and Intel Arc Alchemist Plus. Arrow Lake also uses the same low powered cores with a new Intel GPU architecture but loses hyperthreading without the new rentable units. I am unsure about the loss of hyperthreading but the new iGPU might be interesting.

If I can get my current Alder Lake to last as long as yours (8-9 hours), switching to Meteor Lake might be questionable, considering I heard now that the Iris Xe iGPU works on Davinci Resolve and that Meteor Lake battery life isn’t as stellar as it says it should be.

I am more excited for Nova Lake and Rentable Units for my next Desktop (from the current AMD 5900X) though. I have an Arc A770 and I wonder how is Battlemage and Celestial.

1 Like