[TRACKING] PPD v TLP for AMD Ryzen 7040

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

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

1 Like

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.

1 Like

One other thing to note - with Fedora.

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.

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):

  1. PPD on power-saver, pstate status set to active, energy perf pref at power
  1. a. same test via gnome/wayland
  1. 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
  2. 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)

  1. Settings:
    PPD = power-saver
    amdpstate status = active
    energy_perf_pref = power

Observed CPU freq = 400 Mhz - 1.4 Ghz.

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.

Calcs are:
10% battery = 5.5 Wh
55/60 = 0.91667
5.5/0.91667 = 6

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.

  1. 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.

  1. 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.

  1. 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.


Try using sudo cpupower monitor to get RAPL information.


Energy Centre in Plasama(KDE) reports plugged consumption FYI

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
1 Like

Thanks, that includes a useful set of details. Not dissimilar to the ‘Idle stats’ pane in powertop.

Interestingly, it reports max cpu freq and not current cpu freq. ie, see:
cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq

I like to run watch on that to determine how the cpu load impacts its freqs.

Good to know @jwp. If you have a moment to trace its code and determine where it’s pulling or calculating that from, it would be helpful :wink:

I took a quick look here:


Would you mind opening a PR upstream systemd for it then? It seems reasonable to me if there are no negative impacts.

1 Like

It’s part of Info Centre not System Monitor - just poking around in gitlab to see if I can find the upstream of the kcm energy info module.

 18119 ?        Sl     0:00 /usr/bin/kinfocenter kcm_energyinfo

Looks like it’s probing org.freedesktop.UPower.Device: UPower Reference Manual via dbus to get the values.

Great, thx!

So on batt:
upower -i /org/freedesktop/UPower/devices/battery_BAT1

Out of curiosity, does Energy Centre show a constant rate when charging or does it appear to vary with load?

I wonder if it’s showing the charging rate rather than the system energy use?

I’ve also been taking a look at:

Screen shots in this thread ; [TRACKING] Suspend on linux drains a lot of battery compared to other laptop - #86 by jwp

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 :sunglasses:

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.



Oh cool, thanks for those!

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.

1 Like

Yeah it shows a very small drop in idle in power on the system I have as well. I have both DP and HDMI cards connected and it can apply to both.

Here’s the USB IDs for both cards for you to be able to add both to systemd.

32ac:0003 Framework DisplayPort Expansion Card
32ac:0002 Framework HDMI Expansion Card 

I’m a big advocate for optimal automatic defaults wherever possible. For example that’s why I changed amd-pstate to default to active in kernel 6.5 and why I’ve changed the default policy for USB controllers to use runtime PM in kernel 6.1.

The more things like this happen automatically the less that people need to use tribal knowledge to get the best power efficiency and consumption.


upower at least for me is reporting in near real time; where did you get the 2min from?