Debunking Zswap and Zram Myths
This deep technical dive from a kernel memory management expert dissects the often-misunderstood differences between Linux's zswap and zram technologies. It forcefully argues for zswap as the default choice, highlighting its superior kernel integration and automatic tiering over zram's rigid, block-device approach and potential for performance pitfalls like LRU inversion. The article is popular on HN for clearing up common misconceptions with authoritative, detailed explanations, offering practical guidance for optimizing Linux memory management.
The Lowdown
The article, authored by a Linux kernel memory management expert, aims to clarify the frequently confused functionalities of zswap and zram, two technologies designed to compress swap data in RAM. It asserts that while both reduce I/O by compressing pages before they hit disk, their underlying architectures and behavior under memory pressure differ significantly, making zswap the preferred choice for most users due to its superior integration and graceful degradation.
- zswap vs. zram Architecture: zswap acts as a compression layer in front of disk swap, integrating directly with the kernel's memory management to automatically tier cold data to disk and understand page hotness. In contrast, zram creates a fixed-capacity, compressed RAM block device that the kernel treats like any other disk, unaware of its in-RAM nature, leading to issues when it fills up.
- General Recommendation: The author strongly advises preferring zswap unless there's a highly specific reason for zram, and to avoid running zram alongside disk swap, as this configuration commonly leads to LRU (Least Recently Used) inversion.
- LRU Inversion Explained: LRU inversion occurs when zram, given higher swap priority, fills with cold data that was swapped out early, while newer, potentially 'hotter' data is forced onto slower disk swap, actively degrading performance.
- zram Limitations: zram requires extensive manual configuration for features like writeback to a dedicated block device and lacks native LRU tracking for eviction, relying on manual scripts. On servers, its memory usage is opaque and not charged to cgroups, hindering resource isolation.
- zswap Advantages: Its tight integration with memory management allows for dynamic shrinking, proactive eviction of cold pages based on real-time feedback, and the ability to reject incompressible pages. It also effectively reduces SSD wear by absorbing write churn in RAM.
- Performance Under Pressure: zswap offers graceful degradation by continuously and proactively moving cold pages to disk. zram, lacking this integration, abruptly stops accepting pages when full, potentially leading to system hangs or inefficient OOM (Out Of Memory) killer behavior.
- Fedora's zram Use Case: Fedora's use of zram with systemd-oomd and no disk swap is acknowledged as a coherent solution for specific constraints like security/privacy (no persistent data on disk) and proactive process killing, rather than pure memory management optimality.
- Future Direction: Kernel developers are moving towards consolidating compressed swap implementations into zswap, with active work to enable zswap to operate without a disk backing device, which would further diminish zram's relevance.
In essence, the author strongly advocates for zswap as the robust, kernel-managed solution for most Linux systems, offering intelligent tiering and graceful performance under pressure. zram, while simple for diskless embedded systems or highly specific, manually managed desktop environments like Fedora's (with systemd-oomd), presents significant challenges and potential for self-inflicted performance issues when not meticulously configured and understood.