Skip to content

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

fix: General ZRAM Optimizations #2202

wants to merge 3 commits into from

Conversation

PeronGH
Copy link

@PeronGH PeronGH commented Jan 28, 2025

Summary

This PR implements several ZRAM improvements, including:

  • Adjusting the default ZRAM size to match system RAM
  • Optimizing kernel parameters for better ZRAM utilization
  • Updating the outdated README

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.

@PeronGH PeronGH requested a review from HikariKnight as a code owner January 28, 2025 20:54
@dosubot dosubot bot added size:S This PR changes 10-29 lines, ignoring generated files. enhancement New feature or request labels Jan 28, 2025
Copy link
Author

@PeronGH PeronGH left a 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.

@KyleGospo
Copy link
Member

Hi! Thanks for the PR, it's much appreciated.
We actually set all of your options here via tuned, this was broken due to an oversight but was recently fixed. The only thing we differ on is the zram size, can you explain a bit more about why you're using zram matching total ram size here?

@PeronGH
Copy link
Author

PeronGH commented Feb 3, 2025

Hi! Thanks for the PR, it's much appreciated. We actually set all of your options here via tuned, this was broken due to an oversight but was recently fixed. The only thing we differ on is the zram size, can you explain a bit more about why you're using zram matching total ram size here?

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.

@EPOCHvoyager
Copy link
Contributor

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?

when ZRAM compresses over 10GB, the system starts thrashing and FPS drops significantly.

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.

@EPOCHvoyager
Copy link
Contributor

I have run into systemd-oomd on occasion here, so I don't think this is without merit.

@N0VERCL0CKER
Copy link

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?

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.

@xXJSONDeruloXx
Copy link
Collaborator

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

@dosubot dosubot bot added the lgtm This PR has been approved by a maintainer label Aug 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request lgtm This PR has been approved by a maintainer size:S This PR changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants