The Workstation Working Group has been discussing this topic and I think we’ll provide a summary of what’s been said shortly.
One point I’d like to raise is a clarification around process. The working group is of the understanding that it is free to decide what components are shipped as part of Fedora Workstation, irrespective of the decision that FESCo makes about this change proposal. Even if FESCo approves the change proposal, workstation could still decide to keep using power-profiles-daemon, should it wish to do so.
If that’s wrong please let us know - I think that it’s important to be clear about this.
Well, I think ideally, if the workstation working group didn’t want to
do this, they should have said so before the change was approved?
That said, if it’s not ready / doesn’t work out / isn’t in a state the
workstation working group wants to use it, I would think that would be
up to them to trigger the contingency and not do it.
IMHO, technically, FESCo could override a working group, but I can’t
imagine it would wish to do so in a case like this. Cases mentioned long
ago when working groups were setup were things like working groups
deciding to switch to the BSD kernel or disable selinux… things that
would make us question if something was still ‘fedora’.
I think it’s an unfortunate situation that the existing thing is not really
maintained anymore, but the proposed replacement is a good deal more
complex/has a larger footprint.
This is a slightly tricky case because the situation with the proposal is still evolving. For example, power-profiles-daemon was recently unarchived, and discussions with GNOME (where tuned integration will need to happen) have yet to take place. The workstation working group has been waiting to see how things work out.
I wonder if in future we need to clarify the respective roles of working groups and FESCo in the change proposal process. I feel like there might have been one or two other cases where it could have been smoother. (No blame intended there - it could be that the fault is on the workstation side.)
We (TuneD upstream) will implement the PPD compatibility/emulation layer as stated above even if this proposal is not approved, so people will be able to choose which implementation they want to use.
This is a slightly tricky case because the situation with the proposal is still evolving. For example, power-profiles-daemon was recently unarchived, and discussions with GNOME (where tuned integration will need to happen) have yet to take place. The workstation working group has been waiting to see how things work out.
Yeah, it’s hard to predict the future.
But approval of the change doesn’t mean it’s set in stone.
If it doesn’t work out the way the working group wants, it can either
just not land or trigger the contengency plan.
I wonder if in future we need to clarify the respective roles of working groups and FESCo in the change proposal process. I feel like there might have been one or two other cases where it could have been smoother. (No blame intended there - it could be that the fault is on the workstation side.)
This change has not been approved by FESCo yet. I posted our comments in the FESCo ticket prior to last week’s FESCo meeting where it was planned to be discussed, but the FESCo meeting was canceled. Presumably it will be on FESCo’s agenda for this week.
Has anyone done any energy testing on this? Like with an actual watt-o-meter? p-p-d was designed to have low overhead and not burn a lot of energy in the idle state. tuned doesn’t seem like that’s a core design tenant.
From a high-level, just knowing what I know about trying to get battery life down this past cycle, it seems like there is a lot of monitoring that goes on with tuned. Add on top of that Python and the number of CPU wake-ups involved, I’m going to lean on the side that it would have to be doing drastically better things to make up for all the energy burn in the process.
Having a compatibility shim is certainly nice, but not if it’s going to put us in a worse place with laptops.
We’d have to do some measuring to check. I don’t, myself, have a power meter accurate enough to be useful for this, but I’ll ask the team to use the one in the lab and see if we can measure and compare the two; if that would be helpful.
Just as an FYI in case it’s interesting, this would tie into the energy cert we do and for that there are four key measurements:
Short-idle. Taken when the system has been idle (for I think 5 minutes). Screen is on but nothing else much is happening.
Long-idle. System is left for 15 mins idle - usually that means it’s asleep with current settings so is the same as:
Suspended.
Off.
Each of these are weighted - with more weight given the lower the power state (so an extra 0.1W when asleep has a bigger impact on the certification than when the system is just idling)
If the monitoring was making a difference, you’d see it in the short idle, and from a energy certification point of view I’m guessing it would be small and unlikely to make much of a difference.
As a side note, I will add that I’m currently in a world of pain because the Linux numbers are sometimes worse for Linux than Windows which has become a problem. And if interested, the Fedora numbers usually compare well with Ubuntu (with the exception of where Nvidia vs Nouveau comes into play - but that’s a different topic)
Hello @mattdm , @hergertme and @mpearson ,
I have the capability to test power states with meters I have for my industrial electronics repairs I do. Can you give me the test criteria so I can try to do some testing on this?
It would be premature to test anything before there is even a compatibility shim in place.
But once you have that, I would expect a number of profiles to be tested, in a number of systems to at least ascertain the overhead comparison between the two. We should not be seeing wake-ups on the CPU beyond very occasionally. So things that get run often, like once a second, once every few seconds, or are not completely idle when the system is idle, are going to have real effects on energy consumption.
For example, even thermald is pretty bad right now if you’re not on certain hardware with evented notifications (requiring polling for thermal status).
True, but shouldn’t we be looking at what ppd does atm as well. I mean if we already have some details of that good but I doubt there has been a procedure written to do a proper test of whatever hardware we want to test with.
I have some bench meters and an mso at my disposal. But I think we need metrics that are produced at the consumption source to be accurate, so the drain on the battery. This will be intrusive as a consequence I would think, and is likely why @mpearson is talking of having the lab look at it (for Lenovo).
@mpearson ?I would gladly do any testing on a newish Lenovo if you wanted to send one to me for testing, along with your lab’s details on their test regimen.
True, but shouldn’t we be looking at what ppd does atm as well.
Sure. It’s well documented in the repository how it works.
From the Sysprof perspective, I don’t ever recall seeing any samples showing up on a system-wide profile so it’s likely idle except in response to D-Bus RPCs.
We have certified wattmeters like e.g. Chroma 66202 and others, but I will not post any comparison, because as a TuneD upstream, I am in a conflict of interests, but for anybody doing comparison, please use the latest github commit when the Add a plugin for the ACPI driver by zacikpa · Pull Request #573 · redhat-performance/tuned · GitHub is merged or wait for a new TuneD release, i.e. anything newer than tuned-2.21.0, because the features like e.g. ACPI platform profile can have big influence on the results.
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 would like to add as I stated subsequently on the issue linked above, I would be quite fine with Power Profiles Daemon if it had AMD support, which was my initial real problem with it. If the repo is already forked, my understanding is Tuned is incorporating it into their code. If that is the case would it not be easier to add AMD support to ppd?
Power-profiles-daemon does have AMD support, however I should note that there is currently an issue when a device supports multiple drivers. I.e. both platform-profiles and *-pstate drivers (intel or AMD)
In the asus-linux community, we have noted that setting the energy_performance_preference hints for the intel-pstate and amd-pstate drivers is important for significant power savings on some ASUS devices. The problem is, on a power saving profile, both TuneD and Power Profiles Daemon leave the energy_performance_preference hints to ‘performance’ when they should be set to ‘power’.
On the PPD side, this is an issue with the inability for ppd to support multiple drivers at once. Before platform-profiles existed, there was only the need to support one driver at a time. There is a pull request to fix this, but the contributor needs a few more weeks until he can work on it, see: Draft: support multiple drivers (!123) · Merge requests · upower / power-profiles-daemon · GitLab
TuneD doesn’t have this issue with running “multiple drivers” as it doesn’t have a concept of a driver from what I can tell, it just changes the relevant settings per power mode if that setting is available. All that being said, it has the separate issue of amd-pstate and intel-pstate energy performance preferences not currently being set, which would be fixed with this pull request by myself: profiles: add energy_performance_preference hints to profiles by ryanabx · Pull Request #581 · redhat-performance/tuned · GitHub
One thing I really like about TuneD is that in order to fix my issue with my device, all I needed was to add flags to some of the default configuration files and make a PR, and it appears with PPD that accomplishing the same thing requires a lot more work. TuneD being config-oriented is also nice because any relevant parties (desktop environments, distros, manufacturers, etc.) can choose what flags are set for a “Power saving” profile, as opposed to a “balanced” profile or “performance” profile, or even support more than just those 3 profiles.
