How Linux Uses zswap Compressed RAM Cache

The Linux operating system uses zswap as a lightweight, in-memory compressed write-back cache for swapped pages. When the system experiences memory pressure and begins evicting inactive memory pages, zswap intercepts them before they reach the physical storage drive. It compresses these pages and retains them in a dynamically allocated pool within physical RAM, deferring or eliminating slow input/output (I/O) operations to solid-state drives (SSDs) or hard disk drives (HDDs). This article explains the internal mechanics of zswap, how it integrates into the Linux memory management subsystem, its eviction processes, and its operational advantages.

The Role of zswap in the Virtual Memory Architecture

In traditional Linux memory management, when available RAM becomes scarce, the kernel's page-out daemon (kswapd) identifies anonymous memory pages that are cold or infrequently accessed. Under standard conditions, the kernel writes these pages directly to a swap partition or a swap file on the disk to free physical memory frames.

Accessing disk storage—even high-speed NVMe drives—is orders of magnitude slower than accessing system RAM. zswap mitigates this performance penalty by inserting itself as a middle layer between the memory management subsystem and the physical swap disk. It does not replace the traditional swap partition; instead, it acts as a write-behind cache that sits directly in front of it.

How zswap Processes Memory Pages

The lifecycle of a memory page handled by zswap follows a distinct path through compression, storage, and retrieval:

1. Interception: When the kernel prepares to swap out an anonymous page, zswap hooks into the swap subsystem and intercepts the write operation before a block I/O request is sent to the storage controller.
2. Compression: zswap passes the 4KB memory page through a cryptographic compression algorithm configured in the kernel. Standard algorithms include zstd, lz4, or lzo. The chosen algorithm trades slight CPU overhead for a significantly reduced memory footprint, often compressing pages to one-half or one-third of their original size.
3. Pool Storage: If the page compresses successfully, zswap stores it inside a specialized memory allocator pool (a zpool). If compression fails or the compressed page provides no significant space savings, the operation is aborted, and the page is sent directly to the disk swap.
4. Retrieval (Page Fault): When a process attempts to read a page stored in zswap, a major page fault occurs. zswap locates the compressed page in the RAM pool, decompresses it into a newly allocated standard memory frame, and removes the entry from the compressed pool. This decompression process is significantly faster than reading the block from an underlying physical disk.

The Memory Allocator: zpool

Because standard Linux memory allocators handle memory in fixed-size blocks (usually 4KB page frames), storing arbitrarily sized, compressed data chunks in RAM risks severe fragmentation. To solve this, zswap utilizes dedicated memory allocators called zpools. The Linux kernel supports several backends:

• zsmalloc: Highly efficient at packing variables of different sizes into page frames, offering the highest density and lowest internal fragmentation. It is the modern default choice for high-memory systems.
• z3fold: Capable of storing up to three compressed frames per physical page, balancing low latency with deterministic memory management.
• zbud: A legacy allocator that packs up to two compressed pages per physical 4KB page frame. While it avoids fragmentation, its maximum space efficiency is limited to 2:1.

Dynamic Eviction and Writeback

Unlike other compressed RAM mechanisms, zswap is bounded by a strict memory budget. Administrators define this using the zswap.max_pool_percent parameter, which dictates the maximum percentage of total system RAM that zswap may consume (typically set between 10% and 25%).

When the compressed pool reaches this threshold and new pages continue to arrive, zswap evicts older entries to prevent running the system out of usable uncompressed memory:

1. zswap selects the oldest compressed pages using a Least Recently Used (LRU) policy.
2. The selected pages are decompressed in-memory.
3. The uncompressed pages are written to the actual physical swap device on disk.
4. The space occupied by those pages in the compressed RAM pool is freed.

This dynamic eviction ensures that the most active working set stays compressed in RAM, while cold, inactive data gracefully trickles down to storage devices.

zswap vs. zram

A common point of confusion in Linux system administration is the difference between zswap and zram:

• zswap requires a backing physical swap device. It dynamically sizes its memory footprint based on demand, evicts data to disk when full, and requires zero upfront disk-to-RAM mapping.
• zram creates an independent virtual block device entirely in RAM. It presents itself as a standard block device on which a swap filesystem is formatted. It does not require a physical drive, but it cannot evict excess pages to disk if the allocated space runs out (unless specifically configured with secondary backing storage).

Key Performance Benefits

• Reduced I/O Bottlenecks: Compression and decompression consume minimal CPU cycles on modern multi-core processors, converting slow disk I/O waits into fast, compute-bound tasks.
• Hardware Longevity: By preventing countless random write operations to solid-state storage, zswap reduces write wear on SSDs and eMMC storage chips.
• Higher Effective Capacity: Systems can handle memory-intensive workloads that exceed physical RAM limits with little to no noticeable performance degradation, avoiding early invocation of the Out-Of-Memory (OOM) killer.