Debunking Zswap and Zram Myths

Debunking zswap and zram myths

tl;dr:

If in doubt, prefer to use zswap. Only use zram if you have a highly specific reason to.

In terms of architecture:

zswap sits in front of your disk swap, compresses pages in RAM, and automatically tiers cold data to disk. It integrates directly with the kernel's memory management and distributes pressure gracefully. zram is a compressed RAM block device with a hard capacity limit. When you put swap on it and it fills up, there is no automatic eviction, and the kernel has very little leverage to do anything about the situation. The system either OOMs or falls back to lower-priority swap, causing LRU inversion. It only really makes sense for extremely memory-constrained embedded systems, diskless setups, or cases with specific security requirements around keeping private data off persistent storage.

My advice is:

Do not run zram alongside disk swap wherever possible. In such setups, zram fills fast RAM with cold, stale pages while pushing your active working set onto slow disk, making things actively worse than if you had no compressed swap at all. If you must use zram, pair it with a userspace OOM manager like systemd-oomd or earlyoom. Without one, the kernel's OOM killer can leave the system hung for minutes before acting. On servers, zram has additional significant problems. One major one is that its memory usage is totally segregated from the rest of the system, and as such is not charged to any cgroup, breaking isolation semantics.

Architectural differences

Most people think of zswap and zram simply as two different flavours of the same thing: compressed swap. At a surface level, that's correct – both compress pages that would otherwise end up on disk – but they make fundamentally different bets about how the kernel should handle memory pressure.

zram's block device architecture

zram acts as a compressed block device, essentially a virtual disk in RAM. When a process needs to swap, the kernel treats swap on zram like it does on any other block device, sending I/O requests through the block layer. Importantly, once zram fills up, it's just another storage device that's reached capacity. There's no automatic mechanism to move data elsewhere, which means cold pages that were swapped out first stay locked in fast RAM with no way to evict them.

Furthermore, because the kernel sees it as just another storage device, it applies normal disk-oriented defaults to it (like vm.page-cluster). While these defaults make sense for physical disks to amortize seek times, they often work against zram's performance by polluting the swap cache with unneeded pages.

zswap's memory management integration

By comparison, zswap doesn't create a block device at all – it integrates directly into the kernel's memory management subsystem. Because zswap is woven into the reclaim path itself, the kernel actually knows which pages are hot and which are cold. When the compressed pool fills up, zswap can evict the least recently used pages to your backing swap device, aiming to keep your hot data present in the compressed RAM cache. This provides automatic tiering and gracefully degrades as memory pressure increases.