This also affects KDE (@ngraham) and Budgie (@joshstrobl) too, as both use power-profiles-daemon.

My vote would be for un-archiving the repo so a new maintainer can be found. The fact that it was archived before this could happen basically prevents it from happening at all, since the repo is now read-only and hence no one can volunteer to do so or communicate with the former maintainer about it.

I agree. It should also probably be moved into its own group namespace on the FreeDesktop GitLab so that multiple maintainers can join in.

Related: https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon

Hi,

I'm trying to unarchive the repo and take on the maintainer. Could you please allow me a bit of time to resolve it? Also, I submitted the change proposal which Allan pointed out.

Thank you :)

Related: https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon

I asked Bastien for comment on this proposal and his feedback is:

Replacing power-profiles-daemon with tuned is like replacing your bonsai scissors with a constantly running chainsaw. Sure you can trim your miniature tree with it, but why would you want to use that tool for the purpose.

Tuned doesn't have profile holds, tuned does a lot lot lot more than change profiles and opens up a huge attack surface compared to ppd. tuned is a testing tool, not something to use to build a product.

Maybe Bastien can un-archive his repos so they don't look 100% dead and freak people out and make them want to replace those projects with alternatives?

Hi,

As the proposal mentioned, we plan to integrate the power management tools, such as ppd, tuned. Both of them provide similar functions but they can't run together. Ordinary users don't understand what those tools do and may install all of them. Consequently, they get a bad user experience.

Moreover, the plan includes porting ppd API to tuned to minimize the impact of components that use ppd API.

Currently, we are trying to gather the comments from folks. If folks think this is a bad idea, we stop doing this and start to make another proposal to integrate them. For example, a proxy layer for those tools.

https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon

For the un-archiving of the repo, I am still trying to negotiate.

For the un-archiving of the repo, I am still trying to negotiate.

The repository is unarchived and has moved to https://gitlab.freedesktop.org/upower/power-profiles-daemon.

Ordinary users don't understand what those tools do and may install all of them. Consequently, they get a bad user experience.

When tools have a decent likelihood of conflicting in bad ways, should we insist they conflict at the rpm level so there's some level of resistance to such combinations?

I think that makes sense. We explicitly recommend doing that for various packages that conflict with things that KDE Plasma needs; see https://community.kde.org/Distributions/Packaging_Recommendations#Packages_to_avoid.

We discussed this at today's meeting and are struggling to reach consensus on what to do here. It's very good to see that the repository is no longer archived; that is important progress and avoids the most immediate concern.

Still, we need to figure out what to do with the proposal to replace power-profiles-daemon with tuned. The Working Group does not have much expertise in power management and is having difficulty evaluating this proposal. Normally we prefer to defer to expert developers, but in this case our experts @hadess and @smallorange do not agree on the best path forward, which leaves us in an awkward situation.

The general opinion of the Working Group is currently skeptical of tuned. We are not convinced that we should add tuned to Fedora Workstation and currently have no plans to include tuned even if FESCo approves the change proposal. However, we are also not very confident in this choice, so this is not a final decision and we remain open to further discussion.

We are also not satisfied with power-profiles-daemon due to the uncertain maintenance situation and complaints from users. @ngompa in particular believes that we could achieve significantly better power management results by replacing power-profiles-daemon with tuned.

It would be really nice if our power management experts could agree on a path forward, but lacking that, another round of discussion would be nice. We will continue to watch and try to understand both tools better.

When tools have a decent likelihood of conflicting in bad ways, should we insist they conflict at the rpm level so there's some level of resistance to such combinations?

Ah! Very good idea. Shame I didn't think of that sooner. RPM conflicts would probably be sufficient to satisfy users who are unhappy with profiles-daemon killing tuned and TLP when it gets D-Bus activated.

I don't really feel this is a decision that needs to be made downstream for Fedora Workstation. If upstream Gnome and KDE accept this change, then I don't see a major problem with including it in WS

I don't really feel this is a decision that needs to be made downstream for Fedora Workstation. If upstream Gnome and KDE accept this change, then I don't see a major problem with including it in WS

That's a good point and it makes sense to me. Will you be proposing this change upstream, @smallorange ? Having tracking issues we can link to would be helpful.

I know that @smallorange has already been talking to the KDE folks, and I've also discussed this with @nicolasfella. KDE is willing to adapt to tuned, but we'd like to make sure our needs are considered as part of the transition (and ideally not have to do this again anytime soon...).

That's a good point and it makes sense to me. Will you be proposing this change upstream, @smallorange ? Having tracking issues we can link to would be helpful.

@aday, I'm happy to submit the change proposal to upstream. Could I submit the issue about the change proposal to gitlab under Teams/Desing?

Thank you

I know that @smallorange has already been talking to the KDE folks, and I've also discussed this with @nicolasfella. KDE is willing to adapt to tuned, but we'd like to make sure our needs are considered as part of the transition (and ideally not have to do this again anytime soon...).

Hi @aday and @ngompa

We would like to minimize the impact of applications that use p-p-d API. I also talked with tuned and we think a translation daemon can be used to translate the p-p-d API to the tuned API. In this way, ideally, the applications can keep the original implementation and it gives us more time to move to tuned API.

@aday, I'm happy to submit the change proposal to upstream. Could I submit the issue about the change proposal to gitlab under Teams/Desing?

The change would likely need to be proposed as an issue to a technical component, likely gnome-control-center/gnome-shell/gnome-settings-daemon. Or you could start a thread on GNOME's Discourse instance and notify the relevant maintainers (@fmuellner, @feborges, @garnacho).

We would like to minimize the impact of applications that use p-p-d API. I also talked with tuned and we think a translation daemon can be used to translate the p-p-d API to the tuned API. In this way, ideally, the applications can keep the original implementation and it gives us more time to move to tuned API.

This is not the best option. There are only a few components that would need to be adjusted (gnome-settings-daemon, maybe gnome-control-center, and their KDE equivalents) so there is simply no need to add a new daemon for compat purposes. It's better to just port everything.

We don't know if other desktops have also implemented the API. It's much more reasonable to have a translation service and port GNOME + KDE first, and verify there are no more consumers after everyone else has been notified, then retire the translation service.

We don't know if other desktops have also implemented the API. It's much more reasonable to have a translation service and port GNOME + KDE first, and verify there are no more consumers after everyone else has been notified, then retire the translation service.

Thank you
That is what Jaroslav (tuned) and I think. That daemon gives more time for the application to migrate to tuned API. If all the customers migrate to tuned API, the daemon can be retired. Ideally, we can move everything to tuned API at the same time. But in reality, considering the other applications use p-p-d API but we don't know about them. This daemon gives them more time to be aware of the change and then move to tuned API. Hope @catanzaro can understand the reason behind this.

I did a Debian codesearch and found the following projects using the power-profiles-daemon D-Bus API: gnome-settings-daemon, powerdevil, gnome-control-center, budgie-control-center, gobject-introspection, thermald, gnome-shell, glib, sysprof, python-dbusmock, and budgie-desktop. It's more than I was expecting.

We are also not satisfied with power-profiles-daemon due to the uncertain maintenance situation and complaints from users. @ngompa in particular believes that we could achieve significantly better power management results by replacing power-profiles-daemon with tuned.

Has anyone run tuned with the profiles suggested as defaults under a watt-o-meter to validate this claim? Or at least with RAPL or something? Burning CPU to not burn CPU sounds like you might end up in a wash.

I currently am running tuned instead of ppd on my workstation, I could be convinced to do some testing for the Workstation WG if they need it. I am following this topic in Discourse, and now here. Also, I have a "watt-o-meter" handily available.

It would be really nice if our power management experts could agree on a path forward, but lacking that, another round of discussion would be nice. We will continue to watch and try to understand both tools better.

I've been monitoring the change proposal discussion. I see Christian has presented some concerns regarding idle power usage. Beyond this, I haven't seen much discussion; notably, there are not many arguments in favor of the switch to tuned, as I would have expected to see after the proposal was soft rejected by both FESCo and the Workstation WG. So I don't think this proposal is currently on track towards eventual acceptance, which is unusual for changes proposed by Red Hat developers.

We are likely to strongly consider feedback from the change proposal discussion, so I'd quite like to see tuned proponents present their case for tuned on Discourse. (It's probably best to keep discussion on Discourse to the greatest extent possible, and leave this ticket for meta discussion.)

If this helps I can give my experiences with the adoption of PPD in Fedora initially, which led me to subsequently remove it in favour of tuned. I have an ASUS Prime B550M-A-WIFI, so it is a desktop with wifi on the mobo. PPD detected this as a laptop I suppose, and as a result wouldn't allow for any power settings other than basic and low power, and wouldn't let me use performance (didn't even give option). I tried to work with it initially, but found it impossible to get more performance out of my system. I switched to tuned and I was able to set the mode I wanted, with very little issues. My use case is not too demanding, but rather more steady use. And frankly I have a very particular dislike of my OS telling me what I am allowed to do with my hardware, even if I apparently want to break it by using however. The other part of my issue was those in support of ppd seemed to think it was quite fine for me to not be able to use performance. I understand the ideal of wanting everyone to use low power devices for everything, but we (collectively) have to arrive at that destinations end at our own pace. Also on the topic of power use hog's (like us NA people are normally classified), a lot of us are more conscious of our power usage than would seem to be the popular opinion.

I think the p-p-d performance mode is only present on certain Intel processors. It requires some sort of hardware feature. I also do not have it. But anyway yes, that certainly seems like an advantage for tuned.

(It might be best to leave these comments in Discourse so that we can keep discussion of the proposal mostly in one place.)

That's a good idea. I'll re post it there. And yes my board is AMD. Honestly if support for AMD was present in p-p-d it would assuage the issue for me at least.

Hi @catanzaro

It would be really nice if our power management experts could agree on a path forward, but lacking that, another round of discussion would be nice. We will continue to watch and try to understand both tools better.

I've been monitoring the change proposal discussion. I see Christian has presented some concerns regarding idle power usage. Beyond this, I haven't seen much discussion; notably, there are not many arguments in favor of the switch to tuned, as I would have expected to see after the proposal was soft rejected by both FESCo and the Workstation WG. So I don't think this proposal is currently on track towards eventual acceptance, which is unusual for changes proposed by Red Hat developers.

Thank you for consolidating the information.

I think we could focus on the advantages on both sides, tuned and p-p-d. p-p-d is simple and offers three profiles to the user. The vendors try to implement the profile through firmware or some kind of method. tuned gives the vendor more room to develop the power profiles through user space program. It allows them to integrate the power feature flexibly. Once the vendor starts to contribute the power profiles. We can expect to see the improvement in the energy utilization and system performance. It would be great if you consider following up on this change proposal.

We are likely to strongly consider feedback from the change proposal discussion, so I'd quite like to see tuned proponents present their case for tuned on Discourse. (It's probably best to keep discussion on Discourse to the greatest extent possible, and leave this ticket for meta discussion.)

That's a good idea. I'll re post it there. And yes my board is AMD. Honestly if support for AMD was present in p-p-d it would assuage the issue for me at least.

So I took a look at the pstate documentation info from p-p-d and from AMD's site. According to AMD the newer processors (like mine) should work in performance mode with p-p-d. So I used their (AMD's) suggested linux commands to check if it was supported by the pstate driver ...

[jakfrost ~]$ cat /sys/firmware/acpi/platform_profile_choices
cat: /sys/firmware/acpi/platform_profile_choices: No such file or directory
[jakfrost ~]$ cat /sys/devices/system/cpu/amd_pstate/status
active
[jakfrost ~]$ sudo ls /sys/devices/system/cpu/cpufreq/policy0/*amd*
[sudo] password for ssnow:
/sys/devices/system/cpu/cpufreq/policy0/amd_pstate_highest_perf  /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_lowest_nonlinear_freq  /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_max_freq
[jakfrost ~]$ cpupower frequency-info
analyzing CPU 2:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.46 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.46 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 4.39 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.46 GHz.
    AMD PSTATE Nominal Performance: 145. Nominal Frequency: 3.90 GHz.
    AMD PSTATE Lowest Non-linear Performance: 88. Lowest Non-linear Frequency: 2.37 GHz.
    AMD PSTATE Lowest Performance: 15. Lowest Frequency: 400 MHz.
[jakfrost ~]$ sudo cpupower frequency-info
analyzing CPU 0:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.46 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.46 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 4.44 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.46 GHz.
    AMD PSTATE Nominal Performance: 145. Nominal Frequency: 3.90 GHz.
    AMD PSTATE Lowest Non-linear Performance: 88. Lowest Non-linear Frequency: 2.37 GHz.
    AMD PSTATE Lowest Performance: 15. Lowest Frequency: 400 MHz.

And it does. I disabled Tuned, uninstalled it then re-installed p-p-d and ran powerprofilesctl which lists all three modes now, and is using the pstate driver. It would appear the p-p-d package has addressed my original issue.

@smallorange had a call with relevant people from GNOME today. Notes can be found here: https://gitlab.gnome.org/Teams/Design/settings-mockups/-/issues/57#note_1947460

Discussion seems to have died down. I don't think we need to revisit this unless there is another future proposal to switch to tuned. Closing for now.