[TRACKING] PPD v TLP for AMD Ryzen 7040

Framework Laptop 13 Linux
7

Also a contact on AMD’s side has expressed that TLP will likely interfere with AMD’s suspend.

I totally get recommending PPD from a support perspective as it’s very predictable. TLP is pretty powerful and difficult to configure correctly (although it can be configured to behave identically to PPD if so desired).

Unfortunately, PPD just doesn’t do half of what TLP does and, well:

  1. It suggests that the other power-saving features in TLP should be enabled by default, but that’s not going to be the case for many (nearly all) users.
  2. There’s an on going discussion about supporting both the AMD P-State EPP driver along with platform profiles.

I’m guessing @Mario_Limonciello can likely weigh in on this question if he has a moment.

8

“This project is archived and cannot be commented on.”, so it looks like the discussion isn’t really active anymore and PPD isn’t actively developed anymore at the moment.

9

Yes, it’s currently archived. However there is discussion to replace it with tuneD and let tuneD provide a compatible dbus interface. You can read more about it in the Fedora change proposal.

You are correct this is a deficiency in the last release of power profiles daemon.

Not only an ongoing discussion, there was a merge request that was being reviewed that added amd-pstate-epp support as well. When the project got archived that merge request got discarded. If not for the fact that tuneD is supposed to eventually replace PPD it might have made sense to fork the project.

The really important part of power profiles daemon is that it specifically has a path to the ACPI platform profile which on the AMD Framework platform is backed by the amd-pmf driver. The changes made to ACPI platform profiles have a path from the kernel to the BIOS to Framework’s EC which allow changing APU coefficients. It’s important that two entities don’t fight over these coefficients because Framework has extra logic in the EC which allows taking into account things like a 65W power supply vs a 90W power supply and what the APU can actually do with more power.

If you try changing these yourself outside of the EC something is going to stomp on the other and you’ll get unexpected results.

I don’t have any specifics to share to this thread but yes; this is something that has been observed. Aggressive configurations in TLP to override runtime PM behavior in the kernel will cause problems for the system; particularly at suspend. All of the important drivers for the AMD Framework systems have correct default kernel policies in the upstream kernel.

I know that software like powertop advertises possible tunables marked as Bad for some things like runtime PM for things like I2C adapters, PCI bridges and PCIe data fabric endpoints, but in practice these don’t matter.

IMO if you still find something that can be configured by tools like powertop or TLP that does have a measurable positive impact it means that a kernel policy knob default should be discussed.

One other thing that’s really important for a good experience is that both GNOME and KDE natively integrate with it. If you install Fedora or Ubuntu it just works.

8 Likes
10

just wanted to mention that I saw significantly better power draw switching to TLP than PPD (since like Stebalien said it allows for much more in-depth customization), and it looks like a lot of other people have too.

2 Likes
11

To support that. I’ have completely switched from PPD to TLP with all settings to maximal power save on Bat and maximal performance on AC for a week and i had no issues so far. There are no Problems with suspend and no problems while switching from AC to Bat and back. The difference between TLP and PPD regarding Battery usage is big. Using PPD in different workloads the power drain is always 2-4W higher than using TLP.

1 Like
12

If you’re seeing better runtime power draw with a TLP config, I suggest looking at measuring power efficiency (using the rapl interface). If you’re less efficient at lower power consumption are you actually better off? It’s a trade off.

Also make sure your measurements are specifically done on battery. Remember framework adjusts APU coefficients from their EC based on adapter connected.

Also, if you can please narrow down specifically what about your config is improving things it can be used to discuss better defaults without TLP in the picture. My knee jerk reaction (guess) would be screen brightness is the biggest contributor which can have a very dramatic impact.

5 Likes
13

[quote=“Mario_Limonciello, post:9, topic:39423”]
The really important part of power profiles daemon is that it specifically has a path to the ACPI platform profile which on the AMD Framework platform is backed by the amd-pmf driver. The changes made to ACPI platform profiles have a path from the kernel to the BIOS to Framework’s EC which allow changing APU coefficients.[/quote]

TLP allows configuring the ACPI Platform Profile via:

PLATFORM_PROFILE_ON_AC=performance
PLATFORM_PROFILE_ON_BAT=low-power

Could you expand on how TLP might fight over this? I.e., any settings that should be avoided?

I ask because, e.g., I’ve configured TLP with:

CPU_DRIVER_OPMODE_ON_AC=active
CPU_DRIVER_OPMODE_ON_BAT=active

CPU_SCALING_GOVERNOR_ON_AC=powersave
CPU_SCALING_GOVERNOR_ON_BAT=powersave

CPU_ENERGY_PERF_POLICY_ON_AC=balance_performance
CPU_ENERGY_PERF_POLICY_ON_BAT=balance_power

Which should be equivalent to PPD’s “EPP” driver.

Yeah, but for anyone not using GNOME/KDE, it doesn’t appear to do anything unless manually invoked (which is probably a major source of “this doesn’t work” complaints). And even then, it won’t, e.g., adjust wifi power saving, etc (although you may be right that the defaults here are sufficient).

1 Like
14

Sorry I don’t have an index of information here to offer on which knobs are safe and which aren’t. Early on in hardware bringup adding TLP was introducing a lot of instability, so we focused on only changing what was needed.
The two things that I know for sure are safe are changing the EPP policy and platform profile. If you find others that you want to do make sure that you properly profile them and confirm energy consumption and efficiency with the changes.

Those specific settings should be fine and make sense to me.

I’m human. If I’m wrong and you found one that really does help feel free to profile it and raise it for discussion.

4 Likes
15

Mario has done answered this directly. As Mario has indicated, if you care to provide data, please do. But this has been answered.

2 Likes
16

Aligning EPP balance_power with platform power low-power has measurable improvements in my testing: ~10W → ~8W playing a 1080p vp9 in Firefox.

To be able to set EPP, the CPU governor also needs to be set to powersave. Further notes and data are available in that repo.

As PPD only sets platform_power and does not change EPP, its “power saving” mode is misleading. Setting platform_power to low-power alone did not have any measurable effect over baseline (stock kernel) in my testing.

3 Likes
17

You only need a little systemd.service to do this I use : GitHub - jothi-prasath/auto-epp: auto-epp is a python script that manages the energy performance preferences (EPP) of amd-pstate-epp

2 Likes
18

Note auto-epp (and auto-epp-go) appears to blindly set the governor and epp flags every 2 seconds via a long-running process.

TLP is event-driven with no daemon or long-running process.

19

Yup - ideally this should be part of power-profiles behaviour. But for simplicity it does the trick

20

I mean you can also set the scheduler on the kernel to default to powersave and then you can ignore doing this from userspace if you just want to trust performance hint calculations

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