The documentation reviewer part of my brain wants to edit this down to just “use power-profiles-daemon”
Hi @Stebalien ,
One of PPD’s main optimization is it doesn’t interfere with AMD’s suspend.
Also a contact on AMD’s side has expressed that TLP will likely interfere with AMD’s suspend.
hope this answers your question. 
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:
- 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.
- 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.
“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.
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
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
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
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
[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
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
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
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
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
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.
Yup - ideally this should be part of power-profiles behaviour. But for simplicity it does the trick
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
Hrm actually you could blacklist the other schedulers and ppd would work perfectly … /me investigates
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
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
Changing the status of this thread to tracking for the time being.