[TRACKING] PPD v TLP for AMD Ryzen 7040

Framework Laptop 13 Linux
21

Hrm actually you could blacklist the other schedulers and ppd would work perfectly … /me investigates

22

You can also pull the MR that was adding support for multiple things (IE platform profile and EPP driver) to your local build.

Here is the MR:
Draft: support multiple drivers (!123) · Merge requests · Bastien Nocera / power-profiles-daemon · GitLab

It didn’t get merged because the project was archived before it got completed.

4 Likes
23

Thanks @Mario_Limonciello ;

adding:

cpufreq.default_governor=powersave initcall_blacklist=cpufreq_gov_userspace_init

to /etc/default/grub kernel args does net the desired behaviour sans any additional software.

2 Likes
24

Changing the status of this thread to tracking for the time being.

25

I’m currently trying to understand a bit better what linux powersaving is made of, so I am trying out setting config values on my own without TLP and PPD (Arch install with custom sway based dektop).

So far I have done the following:

  • cpufreq governor to powersave (driver is amd-pstate-epp)
  • ASPM to powersupersaver
  • energy_performance_preference for every core to power
  • Disabled the NMI watchdog
  • power_save for snd_hda_intel
  • platform_profile set to low-power

That nets me a little below 5W (powertop) while sitting absolutely idle on desktop with nothing running other than foot terminal with powertop in it, display on lowest brightness and wifi connected. Playing 1080p25 VP9 on youtube in firefox is 9.5W.

So what do PPD or TLP do to get the additional 1-1,5W saved that some people here reach? Or might this just be hardware differences, e.g. RAM/SSD?

26

My notes:
Biggest differences not mentioned there:

  • bt disabled nets a watt or so.
  • hardware switch off for the mic and usb - decreases idle draw
  • Single stick of RAM will make an appreciable difference
  • Not having expansion ports 3/4 connected if you don’t need them

Using PPD only here without any powertop tweaks I get 4.8W idle (with 2x64GB Sticks of RAM). I’m not convinced NMI watchdog needs tuning, and at least for me ppd sets the power save flag for the sound card fine.

I do blacklist the performance and userspace governors to avoid needing any fixups in ppd behaviour not setting epp bits.

1 Like
27

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

1 Like
28

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?

29

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
30

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.

5 Likes
31

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.

4 Likes
32

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

  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.

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.

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.

5 Likes
33

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.

5 Likes
34

Try using sudo cpupower monitor to get RAPL information.

2 Likes
35

Energy Centre in Plasama(KDE) reports plugged consumption FYI

36

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
37

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:

38

Sure.

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

1 Like
39

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
40

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