But… Why? If ZRam uses RAM as compressed swap, what advantage does it have over just leaving that RAM available as shared memory? Do you have a specific process that is eating up non-shared? This might be of interest: https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
You get more ram for very little slow down, that also, would rarely be the bottleneck. For the servers, ram is a constraint, and it’s all just selfhosting. I have a Raspberry Pi that I selfhost with, as well as a couple 10 dollar compute instances in the cloud. More ram is much better than the tiny slow down that might occur during compression or decompression. All my services are all still very snappy, even the mailserver. For my work, I bring up large docker sandboxes of services that I need running to test entire systems. In the past, I would just allocate 32GB to a swapfile. ZRam is way faster.
But you also get that with shared memory in zswap, with all the other advantages. I’d really recommend reading the “Architectural differences” in the linked article from Chris Down, as he’s way deeper into the kernel code than me, but the biggest problem in a setup like a small memory server is:
If you have a ZRAM device, and it fills up, more recently needed pages end up on the backup disk swap, because ZRAM has no way to move between swaps
Where zswap is built into the kernel memory management layer, so it can automatically decide which pages are cold and put them on disk, while keeping fresh ones in compressed RAM.
I.E. in your use case, zswap is better, not even taking into account all the other details from Chris’ article.
Why not just set kernel swappiness to 1 and not do any of that?
Because I want to encourage more swapping, not less.
But… Why? If ZRam uses RAM as compressed swap, what advantage does it have over just leaving that RAM available as shared memory? Do you have a specific process that is eating up non-shared? This might be of interest: https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
You get more ram for very little slow down, that also, would rarely be the bottleneck. For the servers, ram is a constraint, and it’s all just selfhosting. I have a Raspberry Pi that I selfhost with, as well as a couple 10 dollar compute instances in the cloud. More ram is much better than the tiny slow down that might occur during compression or decompression. All my services are all still very snappy, even the mailserver. For my work, I bring up large docker sandboxes of services that I need running to test entire systems. In the past, I would just allocate 32GB to a swapfile. ZRam is way faster.
But you also get that with shared memory in zswap, with all the other advantages. I’d really recommend reading the “Architectural differences” in the linked article from Chris Down, as he’s way deeper into the kernel code than me, but the biggest problem in a setup like a small memory server is:
If you have a ZRAM device, and it fills up, more recently needed pages end up on the backup disk swap, because ZRAM has no way to move between swaps
Where zswap is built into the kernel memory management layer, so it can automatically decide which pages are cold and put them on disk, while keeping fresh ones in compressed RAM.
I.E. in your use case, zswap is better, not even taking into account all the other details from Chris’ article.