There is a lengthy thread on Reddit about the technical differences. Apparently Zswap will take advantage of the kernel eviction strategy for swap space. Apparently Zram doesn’t have that. To me that never made sense because, you create a Zram block device and then set that as your storage for swap space. Why would the kernel care, or know, that the swap space is backed by a Zram block device.
I do use Zram for my cloud self hosting machines and my dev machine. On the cloud devices they have 1 or 2 GB of ram and on my dev machine I have 32GB of ram. And in both cases it definitely seems like there is swap eviction. I also set the vm.swappiness to 180. Prior to Zram I would set my machines’ swappiness to 10. Swapping is highly encouraged on my machine.
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.
I looked at the article, same as the reddit thread, probably written by the same person. ZSWAP is just not necessary. ZRAM works and doesn’t require disk space w/ 3:1 compression. If I was running out of swap, then yes, I would take a look at ZSWAP to improve my swap situation. It’s just not a thing with ZRAM, not for many years.
There is a lengthy thread on Reddit about the technical differences. Apparently Zswap will take advantage of the kernel eviction strategy for swap space. Apparently Zram doesn’t have that. To me that never made sense because, you create a Zram block device and then set that as your storage for swap space. Why would the kernel care, or know, that the swap space is backed by a Zram block device.
I do use Zram for my cloud self hosting machines and my dev machine. On the cloud devices they have 1 or 2 GB of ram and on my dev machine I have 32GB of ram. And in both cases it definitely seems like there is swap eviction. I also set the vm.swappiness to 180. Prior to Zram I would set my machines’ swappiness to 10. Swapping is highly encouraged on my machine.
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.
I looked at the article, same as the reddit thread, probably written by the same person. ZSWAP is just not necessary. ZRAM works and doesn’t require disk space w/ 3:1 compression. If I was running out of swap, then yes, I would take a look at ZSWAP to improve my swap situation. It’s just not a thing with ZRAM, not for many years.
I.E. for my use cases, ZSWAP is irrelevant.