F40 Change Proposal: Tuned Replaces Power-profiles-daemon (Self-Contained)

Hello @ryanabx ,
Thank you for pointing that out to me. I have taken a look at the AMD documentation and p-p-d’s documentation about this and think I will give it a try out. This makes it sensible to use (according to AMD’s info about amd-pstate) for the newer AMD processors like mine. It should provide better responsiveness from the CPU to demands by software. It shows (to me anyway) that I would likely only see two modes performance and powersave. Anyway, I’ll be trying it out soon on my system, which shows …

[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.

I think in light of what the pstate knobs provide combined with the processor’s capabilities, the powersave and performance labels may be the problem. Maybe it’s time to look at … different labels.

[Edit] I have disabled Tuned, uninstalled it then re-install power-profiles-daemon and do have three states using the pstate driver.

The bug of not supporting multiple “drivers” at the same time still persists though until someone fixes it.

I’ve opened this merge request for review which does it.

1 Like

Users of the MR are reporting great power savings when both the platform driver and the CPU driver are being used. This is what I was expecting, and it’s a great sight to see. All that remains on the power-profiles-daemon side is for the MR to be reviewed.

4 Likes

I agree 100% with this. When systemd-powerprofilesd was forced over tuned I experienced noticeable battery and performance problems. Selecting from 3 profiles isn’t detailed enough for power users and I quickly masked the service to return to tuned. Then I saw that the powerprofiles service was renamed to /usr/libexec/power-profiles-daemon, removing systemd from the name and it overrode me again effectively unmasking itself via update.

The dozens of included tuned profiles are far better for specific use cases and I will continue to mask or disable whatever systemd powerprofiles service tries to replace it.

TuneD now supports energy_performance_preference with profiles: add energy_performance_preference hints to profiles by ryanabx · Pull Request #581 · redhat-performance/tuned · GitHub being merged, and is making progress supporting the ppd API with PPD-to-TuneD API translation daemon by zacikpa · Pull Request #579 · redhat-performance/tuned · GitHub

2 Likes

Hi,

Thank you for updating the information.

I’ve noticed that tuned already did lots of work on it and thank you, tuned team for working on this :slight_smile:
I’ll revise the change proposal and target F41.

1 Like

Hi,I came across the changes regarding Fedora 40 and Tuned, and I also noticed that Tuned recently updated its API compatibility with PPD. I immediately gave it a try, but it seems the results are not very satisfactory, at least on my ThinkPad X1 Carbon 9th.

Firstly, under the Balanced Profile, the overall power consumption of the laptop does decrease slightly, rarely exceeding 15W. However, the standby power consumption is quite poor, hardly going below 10W. Without using Tuned, I can achieve standby power consumption of around 5W under the default PPD. When I checked the status using Powertop, it showed that when Tuned is running, the CPU doesn’t enter the C7 or even more power-efficient modes.

I don’t know if this is an issue with Tuned or something else, but at least for now, it seems to me that Tuned is not necessarily a better choice than PPD.

https://bodhi.fedoraproject.org/updates/FEDORA-2024-75664a0d37

3 Likes

Try to disable “dynamic tuning” this is what we want to use as the default in upstream:

/etc/tuned/tuned-main.conf:
dynamic_tuning = 0
1 Like

Sounds like it’s too late for Fedora 40 to change to tuned. Bummer, but I’ll be looking forward to Fedora 41!

Upstream PR:

1 Like

what does the C7 get to on ‘powersave’ profile in tuned?

I pretty much keep my laptops in balanced (ac) and powersave(battery)
What would really be nice is if there was a hook so tuned would automatically go to powersave when the ac brick is unplugged and go to balanced when on ac (or have some simple way to opt into that behavior)

I was fooling around with autocpufreq to do that but it bugged me that I had to clone that from some git repo and install it. I’d prefer keeping things like that as installed from an official repo via dnf like tuned is.

I turned off both power-profile-daemon and tlp services and now exclusively use tuned

I think even on batery the balanced profile may be better, because it can finish tasks sooner than the throttled powersave profile which could result in less energy consumed in total. But if you insist on auto switching I think you can install hooks to acpid events (/etc/acpi/events) reacting on “battery”, “ac_adapter” events.

2 Likes

Yes, definitely — “race to idle”. This can be true of both computer and human processing: if throttling saves half an hour of battery but slows the interface enough that it takes me half an hour longer do whatever I was working on, that’s not really a win!

Let’s make sure we have profiles that have names that don’t accidentally trick people into making less-optimal choices.

2 Likes

On the other hand if you just want to watch movie or read text and don’t bother slightly more sluggish response than you will very probably get better up-times with the throttled down machine.

2 Likes

Something else I think should happen in tuned that’s proposed in PPD is responding to the AC adapter and tuning EPP value based on that.

The proposal in PPD is that when on battery EPP for all cores is set to balance_power and when on AC EPP is set to balance_performance. This is a kind of “dynamic tuning” but it doesn’t need to be polling like other dynamic tuning does.
It can be done entirely with upower signals sent over dbus. PPD does this with it’s amdgpu panel power action.

Something like this is already in use in the proposal for Amdgpu panel power savings that I sent up for Tuned: Add a plugin for amdgpu tuning of the `panel_power_savings` attribute by superm1 · Pull Request #601 · redhat-performance/tuned · GitHub and could easily be applied to the cpu plugin in tuned too.

1 Like

Question as I normally disable ppd and use TLP instead, does tune offer as many features as TLP?

its crazy that TLP seems to be so much more fine grained, but it has no GUI integration

any update on that? Is automatic switching working in KDE Plasma, where with ppd I can switch depending on AC and battery level?

Closing change proposals for F40. The ship has sailed. Of course we can still discuss if needed, but please open new topics for that.