[RESOLVED] Tuned power manager tunes too low
When I updated yesterday,
powerprofilesctl was replaced with tuned. I typically run my laptop on power saver, but I noticed that when I do so, my PC grinds to a halt. KDE hangs when trying to do anything at all, including pressing meta to open the application menu.
Balanced power mode is not much better. I can only reasonably use my PC when set to performanceSolution:Jump to solution
The new Bazzite 41 release should contain a workaround for this issue, as the variables previously set in
65-memory.conf have moved to now be set as part of the default throughput-performance and balanced TuneD profiles as of this commit: https://github.com/ublue-os/bazzite/commit/b2e4c8bb13edcf4eb2a5f3af527a1a098313d1ba
I haven't tested this yet, but this bug should now no longer occur without my posted workaround after updating to the newest bazzite. I am curious about the behavior of the powersave profile now though, as it doesn't set the vm variables at all...19 Replies
GitHub
New power manager is tuned too low · Issue #1747 · ublue-os/bazzite
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 ...
Interesting. I wonder if your issue is related to this one? https://discord.com/channels/1072614816579063828/1295910472268251208
I have this issue too on my Thinkpad (it's set up to be on Performance when plugged in and Power Saver when unplugged). It also results in other issues like USB not working, programs crashing, the RTC to fall behind (I don't even know how that happens), and the system to hang on shutdown for several minutes.
Let me see if I can reproduce. I'm on the Rog Ally on stable-40.20240922.0 upgrading to the latest stable and have my power profile set to powersaver. Hopefully will get the same results
rog ally does not use tuned
So it will be pointless for me to try and try and reproduce. Lol thanks Antheas 🙂
There are three possibilities:
1. Tuned balanced profile is poorly optimized
2. Kernel arguments being added by tuned that halts performance
3. Both
it's also the
power saver mode, but yeah balanced also grinds to a halt. Dunno whether power saver is worse or not though since both just seem to make things stop working
to be fair, I don't actually know whether it's tuned's fault
it would be interesting to see if it was some other part of the update or if it really is the power managerThis seems to be an ACPI related issue, I recently ran into the same problem on two computers with bazzite, after adding the
acpi_osi=!Windows 2020 kargs the problem disappeared on one of them, but adding the same acpi_osi on the other one didn't workbro you have having so many issues with bazzite ahahah god damn
dude ikr 😂
though actually it's just in general lmao I have issues with Windows and other Linux distros too
Bazzite has had the least number if issues 😂
also yeah its most likely the tuned profile not being too good for your hardware btw
tuned has tons of profiles tho
check out
tuned-adm list
you can set the profiles you want to use on /etc/tuned/ppd.confhow do profiles work? I haven't gone back to that bazzite version yet, but I can look again when I get enough time to re-update my computer
Honestly the biggest frustration I have with TuneD is that the document is incomplete. Some stuff isn't really TuneD's responsibility to document (like setting kernel args - that depends on what your kernel supports) but even some of the plugins that are more specific just to TuneD don't have great docs. https://tuned-project.org/ has some description.
man tuned.conf isn't very helpful. Reading the existing tuned profiles either using the tuned gui or via terminal can be pretty helpful for reverse engineering. If you create a new profile based on power saver and just strip away values one at a time individually and replace the removed values after testing, you might be able to find out which specific part of the power saver config is killing your system and either remove it or modify it to work better for your systemI actually went and tried that with a new tuned profile based off of balanced since I was encountering this issue on my Thinkpad (both on balanced and powersave). I went and disabled each line one-by-one until no more lines were enabled, and the lockups were still occurring even with all lines disabled in the profile. When enabling the throughput-performance profile all the lockups instantly went away.
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:
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:
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 rebootThere is a pull request open to fix this issue in the TuneD github which you can follow here: https://github.com/redhat-performance/tuned/pull/688
GitHub
Explicitly support vm.dirty_(bytes|ratio) and vm.dirtybackground(...
The options interact within these two pairs: when dirty_bytes is set, dirty_ratio is automatically set to 0 and vice versa. Rollback thus does not work out of the box when setting these options via...
Solution
The new Bazzite 41 release should contain a workaround for this issue, as the variables previously set in
65-memory.conf have moved to now be set as part of the default throughput-performance and balanced TuneD profiles as of this commit: https://github.com/ublue-os/bazzite/commit/b2e4c8bb13edcf4eb2a5f3af527a1a098313d1ba
I haven't tested this yet, but this bug should now no longer occur without my posted workaround after updating to the newest bazzite. I am curious about the behavior of the powersave profile now though, as it doesn't set the vm variables at allindeed it does! powersave profile as far as I can tell does its job and doesn't paperweight my pc for 5 min every time I switch to it 😂