After a bunch of research and experience using a zram-only laptop with 16 GB of RAM for intensive workflows, I believe relying exclusively on zram for our swap needs is a mistake. I went down a research rabbit hole, and will summarize my findings here: ## The problem zram's size is inherently more limited compared to disk-based swap, making freezes and OOM kills more common compared to having a larger pool of disk-based swap. With 32 GB or more of physical RAM, there generally won't be any problems because you'll never hit the soft or hard limits of what can fit in even over-provisioned zram. But with smaller amounts (16 GB or less) hitting the limit is fairly easy with heavy workloads. Given high RAM prices, I suspect 16 GB is going to be a common maximum for years to come, exacerbating this problem. In addition, only using zram complicates our hibernation story by providing no disk-backed swap we can write the memory image to (for now; set aside the question of whether we can keep hibernation after enabling secure boot). ## Background info on the problem zram was designed to avoid the need for disk swap on disks that are small, slow, and vulnerable to write-based degradation over time — like USB flash drives, SD cards, and eMMC flash. Those are common in phones, raspberry Pis, and USB live sessions, but not typical desktop and laptop computers, which are KDE Linux's target devices. These days most boot disks are modern SSDs (74%, as of a [2023 survey by Tom's Hardware](https://www.tomshardware.com/news/ssd-and-hdd-statistics-from-easeus)). We're also using zram poorly by over-provisioning physical RAM by 200% with LZ4 compression (average 2:1 compression ratio). Theoretically this should double available memory with practically no I/O or CPU penalty. In practice, using 100% of physical RAM for compressed memory starves the system of uncompressed working memory, causing constant compression and decompression when near the limit and increasing the chance of freezes. I encounter these frequently when compiling software with a lot of apps and browser tabs open. zram does provide a means to write incompressible pages to disk swap via `CONFIG_ZRAM_WRITEBACK`, but it's more primitive than what zswap does, and when it fills up, new pages just go to the slower disk swap. ## Why we adopted zram 1. **Laziness:** easy to set up and bypasses the need to create disk swap. 2. **Speed:** does keep the system very fast — until it drops off the performance cliff! 3. **Copying Fedora:** see https://fedoraproject.org/wiki/Changes/SwapOnZRAM. However reading that over with the benefit of more knowledge and experience, I think Fedora adopted zram for the wrong reasons, and it wasn't a good idea. The reasons stated look dubious to me: <details> > Anaconda and Fedora IoT have been using swap-on-zram by default for years. Of course it works well there; IoT and live environments share the characteristic of using small, slow, fragile flash storage — perfect for zram. Actual installed systems generally have none of these characteristics, so the experience of zram in those environments is inapplicable. > Feature owner thinks it's better to just oom, instead of getting overly aggressive with the zram device size This is not a very user-focused perspective. For normal people, it's a better experience for the system to slow down rather than completely freeze or start killing user processes, with the trade-off of consuming a few gigabytes of disk space to make that possible. > significantly improves system responsiveness, especially when swap is under pressure This is true up until the point when the zram is filled, and then responsiveness disappears entirely. It's performance cliff. And zswap can also provide this benefit with sufficiently well-tuned settings. > more secure, user data leaks into swap are on volatile media; Valid, but you can also solve this by encrypting the disk-based swap file or partition. > "without swap-on-drive, there's better utilization of a limited resource: benefit of swap without the drive space consumption; Disk space is plentiful and cheap these days; saving disk space by worsening performance cliffs is a bad trade-off. > complements on-going resource control work, including earlyoom; > [...] > further reduces the time to out-of-memory kill, when workloads exceed limits; OOMing early is bad. Killing user processes agressively is bad. > improves performance for both "no swap" and "existing swap" setups; Anything is better than no swap, but that's not a common setup. zram is a bad match for supplementing disk-based swap because when full, new pages just go to the slower disk swap device, and that's the opposite of what you want! So zram works best with no other swap space; it's not a very good complement to it. </details> ## What might be better The zswap mechanism built into the kernel plus disk swap. zswap already provides a compressed RAM cache that can delay usage of disk swap. Unlike zram, it's integrated with the kernel's memory management system and plays nicely with disk-based swap. ## Short-term fixes Switch to the zstd:1 compression algorithm which offers roughly 3:1 compression. Then drop the zram provisioning to 100%, which is zram-speak for "let 1/3 of the physical RAM be compressed when using a compression method with a 3:1 ratio". This gives you a working memory size up to 66% larger than the physical RAM size with just a small performance hit compared to using LZ4 which is faster. But that's better than experiencing memory starvation and system freezes. ## Medium-term fixes For the live session where we do want to keep swap away from the disk, keep zram but apply the above tweaks. For the installed session: - Use zswap instead of zram. It serves the same "avoid usage of disk swap" function, but better. Compress with zstd:1 (provisioned with a 33% limit of physical RAM) or lz4 (50% limit of physical RAM), depending on desired performance. - Create a boring traditional swapfile that's equal to physical RAM size. This will allow gracefully-degrading consumption of effectively *triple* the physical RAM. This should be enough memory for anyone. ## Long-term fixes Dynamic swapfile sizing: once the user hits 90% of it, the system prompts them to increase its size. This seems like a nice-to-have, and could allow the initial swapfile to be much smaller than physical RAM (assuming we're willing to lose hibernation again). I don't believe it's a necessity though. ## Further reading - https://linuxblog.io/zswap-better-than-zram - https://chrisdown.name/2018/01/02/in-defence-of-swap.html - https://chrisdown.name/zram.pdf - https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html - https://lwn.net/Articles/1059201/ - https://unix.stackexchange.com/questions/707108/is-increasing-the-max-pool-percent-parameter-for-zswap-a-smart-idea-to-combine-c - https://wiki.archlinux.org/title/Zram - https://wiki.archlinux.org/title/Zswap - https://btrfs.readthedocs.io/en/latest/Swapfile.html - https://www.guyrutenberg.com/2024/12/14/setting-up-a-swap-file-on-btrfs/ - https://rusty-snake.github.io/tricks/2024/07/04/swapfile.html