F41 Change Proposal: Make Tuned the Default Power Profile Management Daemon (System-Wide)

Project Discussion Change Proposals
,
1

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

This Change makes ‘tuned’ the default power profile management daemon in Fedora Workstation, KDE Plasma, and Budgie instead of power-profiles-daemon.

  • tuned-ppd provides a drop-in replacement for power-profiles-daemon, which allows it to be used with current desktops
  • power users can customize the desktop-exposed power profiles by editing /etc/tuned/ppd.conf

:link: Owner

:link: Detailed Description

Tuned and power-profiles-daemon provide a similar function to set and tune the power status of a system. Both of them have similar features, if they can be integrated into one, it allows the Fedora user to have more options for power settings of their system and benefits the users. In this proposal, we set up tuned to the default power profile management daemon for the GNOME in Fedora Workstation and the KDE Plasma Spin. Tuned already provides power profiles for different use cases. Recently, tuned released the translation API layer called tuned-ppd which can translate the power-profiles-daemon API to tuned. The applications that use power-profiles-daemon API can access tuned without modifying the code. For now, the Fedora user can immediately switch to tuned by installing the tuned-ppd package without impacting the user experience. Therefore, tuned can be the default power profile management daemon for Fedora.

This work would replace power-profiles-daemon with tuned. Since tuned already provides a wide range of power profiles for different purposes, this allows the user to have more options for configuring the system power profile. Tuned provides many kinds of advanced and basic profiles for different purposes. Power-profiles-daemon provides the basic power profiles and the profiles can be set to the system through platform_profiles, Intel p-state and AMD p-state. That is simple and clever. However, if the users want to ask for an advanced profile, they need to install another power utility, such as tuned to fine-tune their system. With tuned as the default power profile management daemon, users have a wider range of profiles to fine-tune the system.

Tuned released a new translation API service called tuned-ppd [1]. tuned-ppd can translate the power-profiles-daemon API to the tuned API so applications can talk with tuned without modification. Moreover, the GUI settings, such as gnome-control-center can configure tuned profiles through tuned-ppd. tuned-ppd also allows the user to override the basic three power profiles, including power-saver, balanced, and performance through the config file /etc/tuned/ppd.conf [2]. If the user wants to use a customized profile, they can edit the config file and map the custom profile to the basic three power-profiles-daemon profile names. In this way, gnome-control-center can keep the original design to configure the customized profile.

The work expects tuned to replace the power-profiles-daemons to offer a wider range of power profiles to Fedora users. tuned-ppd resolved the API translation issue so the application can access tuned service through power-profiles-daemon API without converting to the tuned API. Moreover, the three basic profiles can be overridden when the user needs it for their use case. It also benefits GNOME applications that can keep the original design and designing a new GUI tool for custom profiles is unnecessary. Therefore, tuned can be the default power setting service for Fedora.

:link: Feedback

From fedora-devel

Request for comment- tuned replacing power-profiles-daemon plan - devel - Fedora Mailing-Lists 1. The dependency concern. Since tuned is written by Python, that causes a dependency impact on Fedora installation. 2. The power-profiles-daemon API should be ported to tuned to provide the function to the application that uses power-profiles-daemon API, such as gnome-shell and gnome-control-center.

From the hardware vendor

Moreover, we discuss it with vendors through the mail. 1. Since tuned covers several kinds of system tuning schemes that allow the vendor to implement their power profile for different devices or workloads. For power-profile-daemon, it only has three profiles to set and every detail setting should be done through the firmware level. If tuned can replace power-profiles-daemon, they can imagine they can develop the profile in a much more flexible manner.

The previous discussions

:link: Benefit to Fedora

  1. Benefits the user. The user would have more options to tune their system.
  2. Benefits the maintainer. Integrate similar software into one software to reduce the maintenance effort.

:link: Scope

  • Proposal owners:

    • for GNOME: update gnome-control-center weak dependency on power-profile-daemon to tuned-ppd
    • for KDE: update powerdevil weak dependency on power-profile-daemon to tuned-ppd
    • for Budgie: update budgie-control-center weak dependency on power-profile-daemon to tuned-ppd

  • Other developers:

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

Since tuned-ppd provides the ppd APIs and features, there is no impact on other applications.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? Y/N

:link: How To Test

  1. Remove power-profiles-daemon.
    $ sudo dnf remove power-profiles-daemon
  2. Install tuned and tuned-ppd through the following command
    $ sudo dnf install tuned
    $ sudo dnf install tuned-ppd
  3. Run gnome-control-center and switch to the power panel and then select one of the three power profiles. Click the top-right corner of the screen and you can see the “Power Mode” shows the profile name that you selected previously.
  4. Run the following command to show the active profile. Since tuned-adm shows the tuned profile name, the profile name mapping can be found in /etc/tuned/ppd.conf.
    $ tuned-adm active

:link: User Experience

  1. The workstation user can set the power profile through the gnome-control-center.
  2. The server users switch the profile through the tuned command line.

:link: Dependencies

tuned is written by Python so it depends on python packages and its 40 packages.

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)

Use the original power-profiles-daemon

  • Contingency deadline: N/A (not a System Wide Change)

Before F41 beta freeze.

  • Blocks release? N/A (not a System Wide Change), Yes/No

No, tuned-ppd provides all the power-profiles-daemon APIs otherwise the original power-profile-daemon can be used when the plan blocks the release.

:link: Documentation

I have talked with tuned about this information.

:link: Release Notes

Last edited by @amoloney 2024-05-31T09:27:22Z

4 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Added f41, fesco

4

Linking to previous discussions:

5

I think it would be great if we could have examples where this improves on the status quo as right now there were concerns raised that the power consumption was increased when using tuned profiles.

1 Like
6

currently tuned-ppd has conflicts with power-profiles-daemon


which is fine for now, but the change should propose handling that somehow. Either obsoleting power-profiles-daemon or not conflicting with it somehow.

Do we know how much larger this will make media?

7

Since tuned is python based and PPD is Glib/C, I think it would be worth doing some boot time profiling with tuned + tuned-ppd versus PPD across variety of machines (some old, some new, some Intel, some AMD etc) to ensure this doesn’t turn into boot speed regressions.

1 Like
8

This is just one user, but in my experience tuned actually reduces power consumption significantly compared to ppd. This is on an older AMD laptop without platform profile support, so ppd falls back to the placeholder driver and basically does nothing.

It might be worthwhile to conduct a test across both old and new devices. I think this change could be very beneficial to prolonging the lives of old devices.

3 Likes
9

Have you tried PPD 0.21? It should use CPU support on an older platform instead of just a placeholder for platform. I would expect parity with tuned master and PPD 0.21.

10

I have. It still uses the placeholder driver - my CPU doesn’t support amd-pstate. The power consumption is lower on tuned (power saving profile) while idling and while using a browser. I use powertop to measure and then compare the watt numbers.

11

Got it; makes sense then. But I’m still surprised tuned does anything different. The knobs it changes are the same as it pertains to CPU.

12

Looking at tuned-ppd.py it appears to be using import dbus which in turn uses libdbus.

It’s been my understanding for the better part of 15 years that we don’t want to be using that in new code.

3 Likes
13

With my Fedora KDE hat on, I’m excited about switching over to TuneD, as it’s much more powerful and flexible for integrators to work with. We have many more opportunities to improve power management than we do with power-profiles-daemon (since tuned is not limited to firmware thermal profile stuff).

That said, we’ll probably want to have a slightly cleverer way to handle the transition from ppd to tuned-ppd.

5 Likes
14

Hi, I see you have many commits in both tuned and power-profiles-daemon. Does this mean you are OK with the change if there are no significant boot speed regressions? I assume you would have complained if you didn’t like the proposal?

15

Hi, I see you have many commits in both tuned and power-profiles-daemon.

Yes I’ve contributed heavily to power-profiles-daemon, and when I heard there was interest in moving to tuned I ported all my changes over so that we could have parity with both.

I still have other changes planned to explore for power-profiles-daemon (for example NVME power state tuning? (#156) and Add support for Workload hints from other software (#140)).

If the first one happens it will be kernel work followed by userspace work that I expect will be easy to port to tuned as well, but the second would introduce a new interface to power-profiles-daemon for GNOME and KDE to interact with that tuned-ppd will need to pick up.

Does this mean you are OK with the change if there are no significant boot speed regressions?

On a technical basis I don’t see problems with tuned besides possible boot speed implications. HOWEVER at the same time; I don’t really see any significant advantage to it.

I have been working in the kernel and systemd for a while now at setting policies appropriately for drivers whenever possible so that userspace doesn’t need to touch 1500 sysfs files to get a system with good power consumption. So I would be surprised if a modern system running a modern kernel actually gets different power consumption results with tuned.

I assume you would have complained if you didn’t like the proposal?

I worry that if you make it “too easy” to change knobs (for example a tuned conffile) then you paper over “real issues” in the kernel or policy that are “tougher” to solve properly. If you look over what PPD does it’s very intentional that PPD only touches a limited number of things instead of the kitchen sink. Debug knobs to change behavior are added to flags, and the intent is that if they need to be used “regularly” for something then the policy in PPD might be wrong.

5 Likes
16

Hi,

I’m glad to know you like the plan. :slight_smile:

That said, we’ll probably want to have a slightly cleverer way to handle the transition from ppd to tuned-ppd.

I did think some plans to make the switching between two applications easier. For example, upower can offer a switching apps (ppd/tuned) feature or a new application for the proxy layer. But consider the API issues, all the gnome applications access the power profile stuff through ppd API. It will cause conflict since the applications should provide ppd API. Moreover, the proxy solution may increase the response time and require the implementation of another layer API between the proxy app and ppd. If we want to provide a wider range of power profile settings and minimize the effort of changing the codes, tuned is a better solution for now, I think. The users can still install the power profile tool they prefer.

17

tuned-ppd is PoC compatibility/transition layer which TuneD upstream will support as long as needed. TuneD upstream do not plan to develop/add more features to it, but PRs will be accepted. I know libdbus has its problems, but it should be OK for this task. If not, it shouldn’t be much problem to replace it by something different. Could you propose some simple lightweight library?

18

There is no black magic behind it. TuneD profiles do what probably other similar tools also do, thus the power consumption should be similar. If not, there is probably bug or missing feature that can be addressed by future updates (this is valid for any similar project, not just TuneD). I also don’t think that several mWh difference is valid metric here. I think the benefit of TuneD is possibility of customization (probably not utilized by many Fedora users) and also the included performance profiles which were used in Red Hat Enterprise Linux. For benchmarks please use the latest release: tuned-2.23.0 and please report found problems.

19

It’s started in parallel with other services. I think it shoulnd’t cause significant delay of the boot process of Fedora (which itself isn’t the fastest distro regarding the boot), but I would also like to see some benchmarks. I will not benchmark it myself, because as a TuneD maintainer, I am biased. I would also like to point out that TuneD is used for more than a decade in Red Hat Enterprise Linux (versions 7, 8, 9) where it is enabled and started on boot by default. AFAIK there haven’t been related performance problems, but IMHO in the enterprise world the boot times usually aren’t critical.

20

I think it shoulnd’t cause significant delay of the boot process of Fedora (which itself isn’t the fastest distro regarding the boot),

That (highlighted from your comment) is exactly why I wanted to make sure we don’t cause regressions and make anything worse :slight_smile: .