[RFC] make tuned as the primary power management tool in Fedora

[smallorange]

Hi,

We have a change proposal for the power management tool which can be found here and we would like to replace power-profiles-daemon with tuned or integrate them.

Both power-profiles-daemon and tuned provide similar functions. However, power-profiles-daemon (ppd) provides the basic profile. If the user needs more options for their system, the new features should be implemented in ppd but tuned already have. If tuned can replace ppd in Fedora, users get a wider range of power options to set up their systems.

To make sure the application that uses ppd API runs correctly, the ppd API and platform_profile features need to be implemented for tuned. Therefore, applications, such as gnome-control-panel, gnome-shell, sysprof...etc. will not be impacted and we have more room to move to new APIs. I knew the concern was about the dependency and installation overhead but the benefits for the user are greater than the installation overhead. If the replacement plan is not good, we also plan to make a proxy layer between user applications and tuned based on ppd.

Comments are appreciated and help us to tweak the plan.

Thank you :)

[yarda]

Hi, thanks for the info.

Unfortunately, I am not familiar with PPD, could you summarize what is missing on the TuneD side / point to the API description? We could either emulate it or provide short-term translation/emulation daemon. Or could the projects switch to the TuneD API? It's long-term stable, backward compatible DBus/socket API (we keep the compatibility for more then 10 years now). Also PRs are welcome.

[smallorange]

Thank you :)

ppd provides platform_profile [1] and Intel/AMD p-state (I believe tuned already has these) settings with one API. It detects the system and chooses the suitable driver to configure the power profile. For the short term, a set of ppd-compatible APIs is needed for that application that uses ppd API. For the long term, we need to persuade and ask the developer and maintainer to move to tuned API. I am collecting comments from the communities, vendors...etc. If they are happy with that, we'll start to run this change project.

[1] https://docs.kernel.org/userspace-api/sysfs-platform_profile.html

[smallorange]

Hi Folks,

The discussion about the plan can be found here
https://discussion.fedoraproject.org/t/f40-change-proposal-tuned-replaces-power-profiles-daemon-self-contained/94995

If you could join this discussion that would be great and your comments are appreciated. :)

[yarda]

NP, I joined the discussion.

[yarda]

Tracker for amd-pstate support:
https://issues.redhat.com/browse/RHEL-16469

[yarda]

Tracker for the ACPI platform profile support:
https://issues.redhat.com/browse/RHEL-16966

[smallorange]

Thank you and the vote can be found here https://pagure.io/fesco/issue/3103

[jadahl]

For the long term, we need to persuade and ask the developer and maintainer to move to tuned API.

From GNOME's point of view, that either means a GNOME side wrapper daemon for user facing "simple" profiles, or some library that provides the equivalent functionality. In the end, what we can't have is multiple places trying to figure out what "dynamic" vs "power save" means in low level terms.

[yarda]

We will provide tuned-ppd RPM subpackage which will include D-Bus daemon that will provide minimal subset of the PPD API - the current PPD API isn't complex, but I expect that most of the projects don't use 100% of it, thus it would be great to have some minimal subset of the API defined for us not to implement everything.

[jadahl]

I'm not saying it's complex, only that there are multiple places in GNOME that expects something like

• Performance
• Balanced
• Power Saver

and when you change that in one place, it should be reflected elsewhere, and what it actually means in terms of what is actually changed behind the scenes should not differ depending on what it was that changed from e.g. "Power Saver" to "Balanced".

There is also the power management daemon that may try to hold certain profiles temporarily (e.g. hold "Power Saver" while the battery power is low).

Where this high level abstraction should live is the question I'm asking (short term vs long term).

[yarda]

TuneD has the switch_profile method and has throughput-performance, balanced, and powersave basic profiles. This is there for cca. decade. Currently, we don't plan to add logic for auto switching profiles e.g. according to the battery charge level or temporarily holding profiles - upper layer should handle it and just tell TuneD which profile to use.

The tuned-ppd daemon will provide ActiveProfile property and will probably map the PPD profile names to the TuneD profile names. It can filter out other TuneD profiles or provide them all, this needs to be agreed on. It will also provide HoldProfile and ReleaseProfile methods. It could provide Actions, PerformanceDegraded/Inhibited but the question whether it's really required.

[jadahl]

Currently, we don't plan to add logic for auto switching profiles e.g. according to the battery charge level or temporarily holding profiles - upper layer should handle it and just tell TuneD which profile to use.

Indeed, this is currently handled by gsd-power (part of gnome-settings-daemon) in GNOME. It does use a "hold" API, however, which means it expects something else to know what profile is "selected" so that it'll return to it after a hold is released (e.g. power is plugged in).

The tuned-ppd daemon will provide ActiveProfile property and will probably map the PPD profile names to the TuneD profile names.

So will this be something that is expected to stay in tuned long term?

[yarda]

Currently, we don't plan to add logic for auto switching profiles e.g. according to the battery charge level or temporarily holding profiles - upper layer should handle it and just tell TuneD which profile to use.

Indeed, this is currently handled by gsd-power (part of gnome-settings-daemon) in GNOME. It does use a "hold" API, however, which means it expects something else to know what profile is "selected" so that it'll return to it after a hold is released (e.g. power is plugged in).

TuneD has the active_profile method that returns which profile is actually selected.

The tuned-ppd daemon will provide ActiveProfile property and will probably map the PPD profile names to the TuneD profile names.

So will this be something that is expected to stay in tuned long term?

I think we can support it as long as it is needed, but we don't plan to develop this PPD interface any more.

[smallorange]

Hi Jonas,

Thank you for the suggestion and information.
The first step and the short-term of this proposal is to make sure tuned can be integrated with the applications that use ppd API. Ideally, we hope the change will not impact any applications. In the meantime, the necessary behaviors, such as ActiveProfiles, Hold/ReleaseProfiles...etc. could be developed. While everything are mature enough, the applications will switch to using tuned API.

Hi yarda,

Thank you for providing the solutions.
Moreover, we have to look into the profile name. Since ppd only has three profiles, including performance, balanced, and power-saver and they have already been implemented in GNOME, I think the ppd profile name should be kept and should be translated to throughput-performance, balanced, and powersave or ACPI platform-profile names through the tune-ppd. I can also help with this. :)

[superm1]

The following PRs are still needed to make tuned perform the same way PPD does.

#601, #616, #618