This is my full kernel boot line in /etc/default/grub for reference:
amd_pstate=active amdgpu.ppfeaturemask=0xffffffff amdgpu.sg_display=0 cpufreq.default_governor=powersave initcall_blacklist=cpufreq_gov_userspace_init,cpufreq_gov_performance_init pcie_aspm=force pc
ie_aspm.policy=powersupersave
This combined with kde plasma energy profile tweaks to change the platform energy preference to powersave on battery and balanced on ac in addition to one of the approaches to fixing up the energy preference to power mentioned in this thread results in 3.7W ish average draw in idle (20% screen, btoff, mic/cam hardware switch, firefox open) in plasma on fc39
What does this do? I think I used something similar years ago to unlock overclocking on my RX480, but does it need something in userspace to be useful for saving power?
It exposes all the available tunables to userspace as r/w rather than r/o amongst other things.
It can be problematic, and it’s mainly useful on Desktop GPU where you want to undervolt. I haven’t noticed anything becoming unstable nor anything affecting power with it set on the amd fw13 so I’ve left it on.
If you - like me ; install libvirtd/cockpit Virt Machines management at all. It by default will setup a virbr0 network device and set it to come up on boot.
Due to various hooks with nftables/firewalld for metrics/mac level blocking and sanity bits setup by libvirtd created interfaces this bridge will consume 2-3W’s by just being active.
So unless you are running VM’s use nmcli and set it to disabled on boot to save 2W.
This doesn’t occur with manually created bridge/tap combo - because it doesn’t plug it into the rest of the systems firewall rules by default.
Likewise there is a guide on improving audio performance via easyeffects - having this consumes another 2 watts or so at any given time by having it setup, and particularly when there is audio playing.
TLDR: Both more performance and longer battery run times are accessible with tuning. I am documenting both below via repeatable methods.
Process:
After boot up, observe power usage and battery %. Once usage stabilizes and batt drops 1%, start a timer. After 10% usage, stop timer, calculate results.
Sysconfig is:
7640u, 2x16GB, Ubuntu 22.04.3 LTS, kernel 6.5.0-1007-oem, X11, XFCE 4.16, Display at first brightness bar with scaling 0.8 (Gnome would call it 120%), connected to 5G wifi, BT off, camera & mic hw switches off, powertop polling set to 10s, keeping battery between 20-90%, UMA gaming mode enabled (4GB gpu RAM)
Completed tests (results below):
PPD on power-saver, pstate status set to active, energy perf pref at power
a. same test via gnome/wayland
PPD on power-saver, pstate status passive, boost off, cpufreq scaling_govenor set to conservative, scaling_min_freq at 400 Mhz, scaling_max_freq at 2.2 Ghz
same as 2) but with pstate status of guided
Next tests:
4) TLP same as 1)
5) TLP same as 2)
6) TLP same as 3)
7) It may also be interesting to review the above with hyperthreading disabled. Perhaps via: $ echo 'off' | sudo tee /sys/devices/system/cpu/smt/control
8) Make sure observation tools aren’t contributing undue power usage (compare draw from powerstat to powertop)
Settings:
PPD = power-saver
amdpstate status = active
energy_perf_pref = power
Observed CPU freq = 400 Mhz - 1.4 Ghz.
Apps:
2 FF windows w/ 4 tabs (reading and typing this message), hw accel off
4 terminal windows (1 powertop, 1 watch -n 2 scaling_cur_freq for all threads, checking uptime/top for system load to ensure updates, trim or something else isn’t running in the background
First up 80-70% lasted 0:55 mins for an average 6.0W draw.
As another data point for this config, after above testing, watching Big Buck Bunny at 1080p with hw decode in vlc indicates a 7.2-8.2W draw. Starts at lower draw, then ramps up to higher draw after 10-20 sec. Typically stabilizes somewhere in between.
Based on 1a. results below, I reran this test in XFCE and this time observed 1:03 runtime. Avg draw 5.24W.
With this in mind, I added ‘Process:’ above to let the system settle in after boot-up before testing begins.
Big Buck Bunny showed 7.5-8.1W.
a. As a sanity check, I switched to Gnome/wayland with the above settings and scaling at 125%. Observed the same cpu freq 400 Mhz - 1.4Ghz. 10% drop in 0:41 or about 8.0W avg draw. Noticed usually high FF activity (80-100% in top, load avg ~=1.5). Rerunning test. The powertop process regularly shows up in top at 20-65%. Second run 1:02 for 10% use is 5.32W avg draw.
Big Buck Bunny at 1080p, hw decoded in vlc indicates 7.4-8.4W draw.
Settings:
PPD = power-saver
amdpstate status = passive
energy_perf_pref = no longer available
scaling_govenor = conservative
scaling_max_freq = 2.2 Ghz
boost = off
Apps: same
Observed CPU freq = 400 Mhz - 2.18 Ghz
Second 70-60% lasted 0:58 hrs at an avg draw of 5.69W
As another data point for this config, watching Big Buck Bunny at 1080p with hw decode in vlc indicates a 7.62-8.69W draw.
Settings:
PPD = power-saver
amdpstate status = guided
energy_perf_pref = no longer available
scaling_govenor = conservative
scaling_max_freq = not followed (listed in /sys/devices/system/cpu/cpufreq/policy*/amd_pstate_* however read-only; the docs indicate these are managed “autonomously”)
boost = off
Apps: same
Observed CPU freq = 400 Mhz - 4.42 Ghz (interesting since boost is off)
10% usage took 0:50 for 6.6W avg draw.
Big Buck Bunny at 1080p with hw decode in vlc indicates a 8.6-9.6W draw.
I’ll edit this post once I’ve documented options 4-6.
Tangential testing based on powertop most thirsty list:
o 2 - 4W for Networking. Disabling wifi had 1/2-1W impact. Good for offline use.
o 800mW - 1.3W is typical for Display backlight at first brightness bar (10%?)
o 900mW - 1.1W USB device: HDMI Expansion. Set to ‘Good’ via Tunable entry and dropped off the map. At most had half the impact as reported.
General observations so far:
a) Two biggest power draws in powertop are Display and Network.
b) Two most active processes in top are FF and powertop
c) iwconfig shows power management is enabled for the wifi driver/card
d) hw video decoding as observed above matches the gpu baseline of 1 Ghz (MCLK) & 800 Mhz (SCLK). GPU load shows 10%. 0-1% load otherwise.
e) The fan stays complete off during the above testing. Temps show between 30-40C (20-22C ambient).
g) As powertop, powerstat and similar tools require running on battery, it may be helpful to see consumption when plugged in. At present, this appears to be reported along with the gpu clocks via: sudo head -12 /sys/kernel/debug/dri/0/amdgpu_pm_info
in other words, this seems to give an approximation of the above tools while on battery even when on mains. Full CPU load can draw as much as 34W!
h) The question between higher or lower max cpu clocks comes down to power efficiency, ie: is it better to complete tasks quicker at higher clocks or slower at lower clocks?
g) Tests 1-3 show enough of a span to warrant continued effort. 13 min delta over 10% equates to over two hours differential on a full charge!
I shared some other observations yesterday via another thread:
This thread seems like a better home for hashing out power usage tuning.
Is there a negative impact to letting the HDMI expansion card go into autosuspend? If not; it should absolutely be added here to the systemd default rules upstream.
Hi @Mario_Limonciello, thank you for your insights in this and other threads.
I plugged in a monitor via HDMI and it came right on.
dmesg indicates things worked as expected:
[23601.253165] usb 5-1: new full-speed USB device number 4 using xhci_hcd
[23601.435828] usb 5-1: New USB device found, idVendor=32ac, idProduct=0002, bcdDevice= 0.00
[23601.435845] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[23601.435850] usb 5-1: Product: HDMI Expansion Card
[23601.435855] usb 5-1: Manufacturer: Framework
[23601.435860] usb 5-1: SerialNumber: XXXX
[23601.515674] hid-generic 0003:32AC:0002.0006: hiddev0,hidraw2: USB HID v1.11 Device [Framework HDMI Expansion Card] on usb-0000:c3:00.3-1/input1
Looks like it is reporting varying charging rate. Which I would assume is being controlled by the EC based on whatever programmed chemistry ideal for the cells.
Not at all! Would you mind testing this on your system before I make the PR?
Might as well double the sample size
I don’t have a DP card but if you do, please test that as well.
First to determine which expansion port has the HDMI or DP: grep -i hdmi /sys/bus/usb/devices/?-?/product
This should give a result such as: /sys/bus/usb/devices/4-1/product:HDMI Expansion Card
Then enable autosuspend by substituting the above #-# into: $ echo 'auto' | sudo tee /sys/bus/usb/devices/4-1/power/control
Personally, this is something I would probably add to /etc/rc.local, however I could see the benefit of including it in systemd if the application is wide enough.
The only other item of interest from: upower --dump
Appears to be: $ upower -i /org/freedesktop/UPower/devices/DisplayDevice | grep energy-rate
It looks like this and BAT1 only refresh every 2 mins. I’ll have to dive deeper into their code to see how the KDE app is getting more meaningful data. In the meantime, powertop & powerstat are giving adequate insights for testing drain while on battery.
