Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New power manager is tuned too low #1747

Open
ngraham20 opened this issue Oct 16, 2024 · 2 comments
Open

New power manager is tuned too low #1747

ngraham20 opened this issue Oct 16, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@ngraham20
Copy link

Describe the bug

When I set the power profile to anything other than performance, my PC grinds to a halt. Basic functions like opening the application menu take > 10 seconds

What did you expect to happen?

When powerprofilesctl was the power manager, I could use power saver mode reliably for all tasks except heavy gaming. This change made it so even balanced is unusable entirely.

Output of rpm-ostree status

State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
Digest: sha256:023e98d12a3f68596c7d99a059a86977d873ac17c7bd105dc770d0cc598545c9
Version: 40.20241014 (2024-10-15T08:59:50Z)
LayeredPackages: firefox plasma-workspace-x11
LocalPackages: 1password-8.10.44-1.x86_64 vivaldi-stable-6.9.3447.41-1.x86_64

ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
Digest: sha256:77b0024fbac46dec3a1957d51e1d4b1570e8c1b9300743b5aa651b3e6af21a9f
Version: 40.20240930.0 (2024-09-30T15:28:49Z)
LayeredPackages: firefox plasma-workspace-x11
LocalPackages: 1password-8.10.44-1.x86_64 vivaldi-stable-6.9.3447.41-1.x86_64

Hardware

Laptop 16 (AMD Ryzen 7040 Series)
Framework 16 AMD 7940HS w/ 7700S dGPU

Extra information or context

No response

@dosubot dosubot bot added the bug Something isn't working label Oct 16, 2024
@TheMCNerd2017
Copy link

I'm having this exact same issue on my Thinkpad P16 Gen 2 with Intel i9-13950HX vPro and a dedicated Nvidia GPU, though it only manifests after the laptop has been running for around an hour while on Power Saver mode. From my experience this also causes the following additional issues:

  • USB devices behave oddly and stop working.
  • RTC falls behind, sometimes up to several minutes.
  • Programs fail to open and currently open programs randomly crash.
  • The system hangs on shutdown, usually due to systemd-journal-flush or ostree-finalize-staged hanging and not exiting. If the former service hangs, /var doesn't get unmounted properly and the journal can become partially corrupt resulting in entries being missing.

This appears to happen on both 40.20241013 and 40.20241014 and does not happen if the laptop is on High Performance mode (except for the shutdown hang due to those two services hanging, which might be another bug introduced in 40.20241013).

@Zeglius
Copy link
Contributor

Zeglius commented Oct 28, 2024

Transcript from Discord from Turtlewit, might be of interest:

I have been experiencing a similar issue, and I believe I found the bug causing it, and potentially a workaround.
The issue I observed was that my system performed normally when it starts on either powersave or balanced, but performance would degrade significantly if I switched to performance, then back to either powersave or balanced (frequent long hitches when interacting with the taskbar, start menu, launching programs, etc). Performance would not improve until I switched back to performance or rebooted my system.
It seems this is caused by a bug with how TuneD manages sysctl variables in the sysctl plugin. The default throughput-performance profiles sets the variables vm.dirty_ratio and vm.dirty_background_ratio. However, when either of these variables are set, they set vm.dirty_bytes and vm.dirty_background_bytes to 0 respectively, as the variables are incompatible. When TuneD switches to a different profile, it restores the values of the _ratio variables to 0, but it doesn't restore the original values of the _bytes variables. Bazzite by default sets the _bytes variables and not the _ratio variables (in /usr/lib/sysctl.d/65-memory.conf). The result of all of this is that all 4 variables are set to 0 when switching away from the performance profile, resulting in severely degraded performance.
The workaround I am using is to override the throughput-performance profile with a custom profile. I created a new directory and config file at /etc/tuned/profiles/throughput-performance-custom/tuned.conf with these contents:

[main]
include=throughput-performance

[sysctl]
replace=1
vm.dirty_bytes = 0
vm.dirty_ratio = 40
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.swappiness=10
net.core.somaxconn=>2048

replace=1 is unfortunately necessary, as the order in which the variables are set is important. This means future updates to the "sysctl" section of the default performance profile will not be propagated to this profile while the profile override exists.
In order for desktop environments to use this profile as the new default performance profile, /etc/tuned/ppd.conf must be updated to change the performance= line to:
performance=throughput-performance-custom

If you named your profile differently, replace throughput-performance-custom with the name of your custom profile.
Edit: forgot to mention, you should restart your system after adding the new profile and editing ppd.conf. I found restarting tuned-ppd with systemctl didn't work when I tried it, I could only restart it with a system reboot
There is a pull request open to fix this issue in the TuneD github which you can follow here: redhat-performance/tuned#688

I tried that throughput-performance-custom profile, and seems it works(?), laptop doesn't suffer massive slow down switching between balanced/perfomance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants