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

Project Discussion Change Proposals
,
21

IMHO, tuned is superior to ppd because it allows to configure various aspects of the sys/hw and not just the cpu states.

RHEL9 ships power-profiles-daemon the first time and conflicts with tuned. I’m interested to switch “back” to tuned via tuned-ppd to consolidate workstation and server configuration.
Albeit tuned-ppd is not in the 9 compose its build in koji. The current versions are

power-profiles-daemon-0.13-1.el9.x86_64
tuned-2.22.1-1.el9.noarch

is the state of this version (tuned-ppd) already usable to replace the dbus api of ppd?

1 Like
22

Is there a comparison of the package / file / storage requirement footprint of ppd and tuned?

ppd seems to be a quite small “native” program (written in C) with few dependencies, while “Python and 40 packages” sounds like a lot. Is there a meaningful difference wrt/ the aforementioned metrics between “Workstation with ppd” and “Workstation with tuned”?

23

Yes, tuned-ppd should be nearly 100% drop-in replacement for the PPD (regarding the API). There are some minor differences that shouldn’t be important for most of the consumers. Feel free to test.

For RHEL-9 we would like to ship tuned-ppd as an alternative to PPD and resolve the conflict (for now it’s not yet officially supported, but hopefully it will be soon).

1 Like
24

and its 40 packages

I think that number is a bit misleading and the dependencies should be comparable roughly. But the experts can chime in more exactly.

Installing tuned-ppd in WS Live pulled in 9 packages for me with a disk footprint of 4.4MB.

It’s anyway pretty hard to imagine a Fedora system without python3, and indeed power-profiles-daemon also seems to depend on it.

2 Likes
25

“Python and 40 packages” sounds like a lot

Most of the packages are installed when installing a new Fedora to a new system. Moreover, Fedora already includes the necessary python3 packages and libraries. It shouldn’t be too bad.

ppd seems to be a quite small “native” program

ppd is simple and is good for now. It provides three profiles and is difficult to expand its capabilities for different scenarios. Think about the next 5 years, 10 years and the increasing user demands. More and more power profiles will be proposed to fulfil many kinds of requirements and system design. tuned offers a flexible way to develop the new profile according to the use case and new system design. If tuned is the primary power profile tool in Fedora, the three ppd profiles will not limit us and the creativity of the contributors and vendors. I think switching to tuned will benefit the users for the next 10+ years.

26

What I mean is that we should ensure both power-profiles-daemon and tuned-ppd have the following stanza in their packaging so they are trivially swappable:

# This is an implementation of the power-profiles-daemon service
Provides: ppd-service
Conflicts: ppd-service

Right now, tuned-ppd has this, but power-profiles-daemon does not yet.

Once both have it, we can change everything that Requires: power-profiles-daemon to Requires: ppd-service.

We can add tuned-ppd in comps so that it gets preferred for installations.

1 Like
27

Hi,

Thank you for the solution.

I’ll try to submit a merge request about it and hope the maintainer will merge it .

28

This change proposal has now been submitted to FESCo with ticket #3222 for voting.

To find out more, please visit our Changes Policy documentation.

29

Hi,

As the original designer of power-profiles-daemon, I haven’t had the chance to reply before to this thread. I was already asked whether switching to tuned with a compatibility was a good idea when this same proposal was made for F40, and now again.

First, tuned already existed when power-profiles-daemon was designed, and the reason why tuned was not used instead of creating a new API was documented in power-profiles-daemon’s README:

Since then, nothing much has changed on tuned’s side that would make it more suited for this task.

First, and as an easy problem to spot, the boot time might very well be impacted by this change. I’ll let others measure its impact on boot up, but I’m sure this problem will show up on systems with slower “disks”.

Second, and most importantly, tuned does a lot. It can be a good thing, if you’re trying to tune a server for a single use case and can verify that it doesn’t corrupt your data for example. It’s not so great when you’re trying to create a product, and not offer too many foot-guns for users to lose their data, and increase their power draw when they meant to reduce it.

It’s great that tuned has this compatibility layer, as that means that folks will be able to test things more easily before figuring out how to upstream them.

But it’s only by upstreaming changes (as Mario, de facto one of the power-profiles-daemon maintainers mentioned above) to where they need to live, into systemd’s rules, into the upstream kernel, that you would be creating a product.

Replacing power-profiles-daemon with tuned in Fedora Workstation would replacing a product with a bag of bits.

/Bastien, not the power-profiles-daemon maintainer

5 Likes
30

I’m pretty wary of this change. Bastien’s stmt that “replacing power-profiles-daemon with tuned in Fedora Workstation would [be] replacing a product with a bag of bits” is exactly what I worry about. But after looking at tuned, I think it’s not quite that bad. Tuned allows users to make tweaks to configuration, but it also provides a high-level interface with a few profiles to select from, and most users are likely to stick to that.

The new tuned-ppd makes it easy to switch between the two implementations. I now installed it on F40 and after starting tuned-ppd.service, the switcher in gnome-shell works exactly as before.

tuned-ppd.service and tuned.service are not in presets. They need to be added if the service is to be started by default (→ 2292636 – tuned.service and tuned-ppd.service need to be added to presets).

The question of installation footprint was raised. The installation is indeed bigger by a few MB, but I don’t think this is a problem for systems where a power mgmt daemon is going to be installed, i.e. usually a system with a graphical environment. The CPU time at startup also doesn’t seem to be big concern. The two services start fairly slowly, but actually consume only 200–250 ms each. The slowness seems to be caused by loading of the myriad python files from disk. The memory usage is 12.7MB and 16.7MB. For ppd, it was 40 ms and 2MB. Extra 28MB of memory use is unfortunately something that might be noticeable on low-end systems.

I see essentially two competing views of the situation: Bastien and Mario think that ppd provides the same functionality and the switch doesn’t bring benefits (and when ppd dosn’t provide something, the proper place to add it is in other components), while the proponents of the change think that tuned will allow additional customizations to be made. Those two views are not necessarily in conflict :wink: . We may experiment with tuned tweaks, but ultimately incorporate those tweaks as changes to defaults in the kernel or udev rules.

There’s clearly quite a bit of enthusiasm for the change, which is an important consideration too. In summary, I think we should try this. If it turns out that we don’t get much change except higher memory and cpu usage, we can always switch back.

3 Likes
31

I have Coffee Lake and on GNOME I can select Power Modes from top-right. As long as I can continue doing that I’m mostly fine with Tuned :stuck_out_tongue:

On Plasma 6 (F40 and openSUSE TW), even though I had specific power plans set to switch with AC or battery, I never saw them switch from the taskbar (AC = Performance; I unplug AC, taskbar still says Performance) and assume profile switching didn’t work at all.

In-lieu of an easy way to adjust CPU perf level (Xfce), I did some quick udev scripts to use x86_energy_perf_policy to set perf levels on AC or battery.

I’ve had issues with USB suspend, heard more than enough stories about AHCI/NVMe, PCIe ASPM and lane speed lowers/suspends, and generally don’t trust any power-saving measures aside from CPU and GPU performance. I’ve avoided TLP for similar reasons, and figure the 3 performance options on GNOME to just adjust CPU performance and is fine.

Assuming the power manager currently on F40 GNOME isn’t doing anything aside from CPU performance, I don’t want to see Tuned implemented and automatically doing ASPM and all the usually-unstable stuff.

32

PPD actually does more than just manage the CPU. Besides PPD, there are also a large number of devices which have autosuspend/D3 enabled in Fedora.

1 Like
33

i did a simple boot test, i’m using an Lenovo laptop with SSD
boot-with-PPD

Startup finished in 2.621s (firmware) + 3.726s (loader) + 1.184s (kernel) + 5.309s (initrd) + 7.863s (userspace) = 20.704s
graphical.target reached after 5.021s in userspace.
Startup finished in 2.612s (firmware) + 3.688s (loader) + 1.192s (kernel) + 5.216s (initrd) + 7.864s (userspace) = 20.574s
graphical.target reached after 4.988s in userspace.
Startup finished in 2.609s (firmware) + 3.659s (loader) + 1.191s (kernel) + 5.263s (initrd) + 7.848s (userspace) = 20.572s
graphical.target reached after 4.986s in userspace.

boot-without-PPD

Startup finished in 2.606s (firmware) + 3.809s (loader) + 1.185s (kernel) + 5.347s (initrd) + 7.937s (userspace) = 20.886s
graphical.target reached after 5.097s in userspace.
Startup finished in 2.631s (firmware) + 3.798s (loader) + 1.191s (kernel) + 5.238s (initrd) + 7.827s (userspace) = 20.687s
graphical.target reached after 4.960s in userspace.
Startup finished in 2.620s (firmware) + 3.703s (loader) + 1.189s (kernel) + 5.290s (initrd) + 7.764s (userspace) = 20.569s
graphical.target reached after 4.875s in userspace.

i’m using fedora kinoite, also how do i stop grub from showing up if i rapidly reboot lol, i needed to wait 3 min before the next reboot, because the grub could show-up and mess with the test

34

Provides: ppd-service
Conflicts: ppd-service

These stanzas were available in the latest ppd package so they can be found in both tuned and ppd packages now.

https://src.fedoraproject.org/rpms/power-profiles-daemon/blob/rawhide/f/power-profiles-daemon.spec#_33

35

Over more than a decade several tweaks were introduced into TuneD which later got addresed in kernel. I think there will be always user space tweaks, because kernel development isn’t fast enough and TuneD can help to bridge the gap with “no support” to “full kernel support”.

Also tuning knobs will be probably always there and TuneD can help to easily handle them. For example system “roles” can be changed by just profile switch (usually without reboot). E.g. system can be tuned for low latency during the business hours and throttled down for low power consumption out of business hours. Or compute node can be re-tuned into SQL server, etc. Probably not useful feature for most regular Fedora users, but the posibility is there.

36

You can add so called “overlay” profile or customized profile into /etc/tuned/profiles and disable tuning of the features you don’t want to tune or aren’t interested in. E.g.: Chapter 3. Customizing TuneD profiles | Red Hat Product Documentation
Just replace the path /etc/tuned in the instruction by the current /etc/tuned/profiles path.

37

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

1 Like
38

Hm. After upgrading Fedora Workstation from 40 to 41, tuned did not get installed, and dnf autoremove dropped the now unreferenced power-profiles-daemon, so no service that provides this functionality ended up installed here. Is that intentional?

2 Likes
39

Looks like you’re not the only one: 2293628 – Make Tuned the Default Power Profile Management Daemon

1 Like
40

I didn’t run dnf autoremove. I still have power-profiles-daemon and no tuned after upgrading to F41. :frowning:

1 Like