-
-
Notifications
You must be signed in to change notification settings - Fork 491
fix: General ZRAM Optimizations #2202
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I've removed the mention of swap file as it was no longer supported, as noted in this forum post.
Hi! Thanks for the PR, it's much appreciated. |
Thanks for letting me know about tuned - I wasn't aware these settings were supposed to be managed that way. Regarding the ZRAM size, I set it to match total RAM because I've run into memory issues with some games, particularly on APU systems where 16GB needs to serve as both system RAM and VRAM. For example, when hosting Palworld multiplayer, ZRAM can compress up to 10GB using zstd (potentially more with lz4). With only 4GB of ZRAM, the game crashes within an hour. Sons of the Forest has similar issues, crashing every 1-2 hours due to insufficient memory. That said, I realize matching total RAM might not make sense for systems with more than 16GB, since they don't face the same memory pressure. Even on 16GB systems, when ZRAM compresses over 10GB, the system starts thrashing and FPS drops significantly. A better approach might be to set a minimum of 10GB ZRAM for all systems, and cap it at 50% of total RAM for higher-end systems. |
I think setting it to half RAM size, maxing out to 8GB should be more than enough - I believe this is the current Fedora default?
Likewise, it might be good to look into setting up a writeback device as mentioned in #1570, to flush out incompressible pages and ease these memory-constrained situations. Though this might come into conflict with the current setup for hibernation. |
I have run into |
I would disagree with putting a cap on it as how much idle memory there is to put in zram tends to scale with memory use not just be a set amount. The only concern I am aware of with putting it to high is that the system might see available swap and not kill programs even if the system is barely responding. Another thing to consider is different ways people use computers as anyone that keeps lots of tabs open in a browser can have most of the inactive tabs thrown into zram without even being noticed. I did a quick test with the monster hunter wilds benchmark, some tabs on firefox, and orcaslicer to see how much I could get in zram before the system was unresponsive. On a laptop with 16gb (14.83gb after hardware reserve) of ram it was barely noticable until around 8gb in zram at which point I could tell it was having to pull thing back out when I alt tabbed. It remained usable until around 13gb in zram at which point the monster hunter wilds bench mark started severely slowing down to a few fps along with everything else. I did manage to hit the oom killer but that was only after it was already slowing down everything enough that I am not sure how well I could have closed it if I had zram set higher. With that quick test and previous experience on other setups I would say setting it to 1/2-3/4 of ram would be safe but above that I would expect occasional problems. |
This has been open for 6 months, can we revisit and make a decision on this one? I'm gonna give it an ack since I recently ran into this issue on a 5700u laptop and OOM killer was a bit agressive, and manually bumping zram allocation and swappiness did significantly improve things. Most handhelds we target should have more than enough storage to spare IMO |
Summary
This PR implements several ZRAM improvements, including:
Background
I've been using Bazzite on my Legion Go for several weeks and noticed performance issues related to the 16GB RAM limitation. Specifically, Palworld multiplayer would frequently crash and occasionally freeze the system due to out-of-memory (OOM) errors.
After experimenting with various solutions, I found that increasing ZRAM size and tweaking kernel parameters significantly improved stability. While I personally use ZSTD compression on my device, I noticed this project switched from ZSTD to LZ4, so I've maintained LZ4 in this PR to respect that decision.
These changes should help users with similar RAM constraints get better performance and stability from their systems.