Zswap or zram on a small Linux server? A live audit

Start with the failure mode, not the compressor

Run a low-memory Linux server with real swap and wonder whether zram would be better? Decide from the machine’s topology, kernel version, and live counters instead of copying a tuning recipe.

The reusable question is not “Which compressor benchmarks fastest?” It is “What happens when compressed memory fills?”

Zswap is a compressed cache in front of an ordinary swap device. Suitable pages stay compressed in RAM; pages that bypass the cache or age out can still go to disk. The disk remains a slower capacity tier.

Zram is a compressed RAM block device. When it is used as swap, its storage still consumes finite physical memory. A zram-only design without a configured zram backing device therefore ends at an in-RAM capacity boundary. Adding lower-priority disk swap does not, by itself, make zram an age-aware cache that automatically moves its oldest pages to disk.

Zram can optionally use an explicitly configured backing device and administrator-triggered writeback on kernels built with that feature. That is a separately managed topology: it does not turn ordinary lower-priority swap into automatic zswap-style eviction, nor does it extend zram’s finite logical device size.

That distinction makes zswap the conservative fit for this server: it already has an 8 GiB swap partition, no zram device, and no requirement to keep swap data off persistent storage.

The host already has a coherent zswap setup

The boot command line contains zswap.enabled=1, and the same argument is present in the default grubby kernel stanza. The runtime switch reports Y. The kernel log closes the loop:

zswap: loaded using pool lzo/zbud

Only the enable flag was added explicitly. LZO, zbud, the 20% threshold, and same-filled-page handling are Linux 5.4 defaults exposed through sysfs.

The 20% value is easy to misread. Zswap does not seize 1.126 GiB when the machine boots. Its pool grows only as pages are accepted and shrinks when entries are loaded, invalidated, or written to the backing device.

The counters show light use, not a tuning problem

After 6 days and 5 hours, debugfs reported:

The page size makes the accounting unusually clear:

89 stored pages × 64 KiB                 = 5.5625 MiB logical pages
2,883,584 bytes of zbud storage          = 2.75 MiB physical pool
2.75 MiB ÷ 64 KiB                        = 44 physical pool pages
(89 entries − 1 same-filled entry) ÷ 44 = 2 ordinary entries per pool page

The readings are consistent with the 88 ordinary entries fitting two per zbud page. Including the same-filled page, zswap represents about 5.56 MiB of logical pages with 2.75 MiB of pool memory—a little over 2:1 before entry metadata.

This is logical-to-pool accounting, not a universal LZO compression ratio. Zbud caps density at two entries per physical page, the debugfs files were read separately rather than atomically, and the counters are approximate under concurrent activity.

The traditional page-swap I/O counters and the partition’s completed writes were also zero since boot. The defensible conclusion is narrow: zswap is active, currently holds a few megabytes, and has not approached a failure boundary. The snapshot does not prove a measurable application speedup.

One swapped page gets a fast path and an escape hatch

A page selected for reclaim follows this path on Linux 5.4:

1. The page has or obtains a swap entry identifying a slot on /dev/sda2.
2. Zswap gets the first opportunity to keep it in compressed RAM. A same-filled page can be represented by metadata alone; an ordinary page is compressed and placed in zbud if it fits.
3. If zswap is disabled, over its limit, unable to reclaim space, or unable to store the compressed result, the normal disk-swap path remains available.
4. On a page fault, zswap reconstructs or decompresses the page and removes the cache entry. If the page is no longer cached, ordinary swap-in handles it.

The backing slot still matters while the payload is in zswap: it gives the page a swap identity and reserves somewhere to write it later. That is why swapon --show can report used swap without proving that the same number of bytes reached the disk.

Replacing zswap with zram would change the operating model

A zram conversion is not a drop-in compressor change. It replaces a cache over durable capacity with a block device whose storage consumes the same RAM the system is trying to relieve.

Zram can be the right design for embedded, diskless, or persistence-sensitive systems. This server has none of those stated requirements. It also lacks a proactive userspace OOM manager, so removing disk-backed capacity would require an explicit pressure and kill policy rather than a one-line swap substitution.

With compressor swap, macOS is topologically closer to zswap than zram

When its backing tier is active, macOS and zswap both keep non-discardable pages compressed in RAM before slower storage. Zram is instead a compressed block device. This is a topology analogy, not an implementation equivalence.

Linux starts with swap identity. A page selected for swap owns a slot on /dev/sda2, and Frontswap gives zswap a chance to cache that page before I/O. The slot remains reserved while its compressed payload lives in zbud. If zswap evicts the entry, Linux reconstructs one full page and writes it through the ordinary swap path.

XNU starts inside the Mach VM object and pager path. Dirty reclaimable pages from internal objects enter the compressor queue; the kernel creates a compressor pager for the object when needed, and vm_compressor_pager_put() stores the page. On a later fault, the pager retrieves and decompresses it. Dirty external-object pages go to their external pager for cleaning; already-clean file-backed pages can normally be reclaimed and faulted back from that pager. Wired pages are not compressor candidates.

The storage geometry is also different. This Linux host’s zbud allocator can place at most two compressed entries in one 64 KiB pool page. XNU packs compressed slots into segments, compacts sparse segments, ages them, and—when its compressor-with-swap mode and backing storage are available—can move eligible segments to swap files. A fault into a swapped segment first brings its populated extent back before the requested slot is decompressed. In short: zswap caches individual pages that already have disk-swap identities; XNU’s compressor pagers map internal-object offsets into a globally managed tier of compressed segments.

Two live ratios, but not a benchmark

A separate Apple Silicon snapshot on macOS 26.6.1, captured with sysctl and vm_stat, reported a 16 KiB page size, 620,095 pages stored in the compressor, and 224,248 pages occupied by it:

Linux: 89 × 64 KiB ÷ 2.75 MiB       ≈ 2.02:1 logical-to-pool
macOS: 620,095 × 16 KiB              ≈ 9.46 GiB stored-page bytes
       224,248 × 16 KiB              ≈ 3.42 GiB resident compressor-data pages
       9.46 GiB ÷ 3.42 GiB           ≈ 2.77:1 stored-page bytes / data-page bytes

The Mac simultaneously reported zero current encrypted swap use and zero cumulative swap-in and swap-out events. That does not mean macOS lacks a backing tier: XNU defines both compressor-only and compressor-with-swap configurations. It means only that this snapshot’s stored pages were not disk-resident. In general, vm_stat’s current “stored” count can include logical pages whose segments are in swap, while “occupied” counts resident physical data pages; neither includes every compressor metadata allocation. Those gauges must not be confused with the cumulative compression, decompression, swap-in, and swap-out event counters.

The apparent density advantage is not a codec contest. The samples came from different workloads at different times; their base pages differ by 4×; zbud’s two-entry layout constrains the Linux pool; XNU packs and compacts variable-size slots; and the two kernels account for metadata differently. The Linux numerator includes one same-filled page with no zbud payload, while XNU’s stored-page accounting includes analogous single-value pages. Neither allocator-footprint ratio says which system has lower fault latency or whether either compressor is optimally sized.

The source comparison uses XNU 12377.121.6, the nearest published release to the sampled Mac’s later 12377.161.13 kernel. In that tag, ARM macOS defaults the compressor payload buffer to 64 KiB, overridable by a boot argument. This is not a 64 KiB VM page: on the sampled 16 KiB-page Mac, the resident or swapped populated extent is page-rounded and can occupy up to four base pages. Apple’s source describes the size as a tradeoff: larger segments reduce end slack and overhead and improve I/O throughput, while smaller ones reduce unnecessary swap-in of data that is not subsequently accessed.

Linux 5.4 is the boundary on modern advice

Chris Down’s 2026 zswap-versus-zram analysis describes a much newer memory-management implementation, using Linux 6.19 examples. The architecture-level lesson transfers: zswap is a cache in front of disk, while zram is a finite compressed block device. The tuning details do not all transfer.

The same rule applies to modern shrinker parameters and per-cgroup writeback controls: do not copy commands for interfaces that do not exist on the running kernel.

The safe plan is keep, measure, then modernize

1. Keep the current topology

• Leave zswap.enabled=1, LZO, zbud, and the 20% threshold unchanged.
• Keep the 8 GiB backing swap partition active.
• Do not add zram beside it as a supposedly faster first swap device.
• Keep the boot argument in the kernel-management path and verify it after maintenance. It appears in the generated grubby stanza, not /etc/default/grub.

2. Measure a real memory-pressure event

A 2.75 MiB pool with zero failure events is good operational news and poor tuning evidence. The next useful sample is the same counter set captured before, during, and after a real deployment, traffic spike, backup, or worker-memory event—not an artificial swapoff on a remote production machine.

Watch these signals together:

Application latency and storage I/O matter more than any one zswap counter. Compare deltas over an interval rather than treating a static value as a performance result.

3. Modernize the platform, not one old knob

The largest technical gap is the 5.4 memory-management implementation. A supported operating-system and kernel upgrade can bring newer zswap storage, cgroup accounting, pressure-aware reclaim, counters, and maintained security fixes together. Validate that change during planned maintenance; do not approximate it by changing the allocator underneath the old kernel at runtime.

Reproduce the audit without changing memory policy

The following commands are read-only:

printf '%s\n' '=== host ==='
uname -a
cat /etc/os-release
getconf PAGE_SIZE
cat /proc/cmdline

printf '%s\n' '=== memory and swap ==='
free -h
cat /proc/swaps
grep -E '^(MemTotal|MemAvailable|SwapTotal|SwapFree|SwapCached):' /proc/meminfo

printf '%s\n' '=== zswap parameters ==='
for file in /sys/module/zswap/parameters/*; do
  printf '%s=' "${file##*/}"
  cat "$file"
done

printf '%s\n' '=== zswap counters ==='
sudo sh -c '
  for file in /sys/kernel/debug/zswap/*; do
    printf "%s=" "${file##*/}"
    cat "$file"
  done
'

printf '%s\n' '=== VM policy ==='
for name in swappiness page-cluster watermark_scale_factor; do
  printf 'vm.%s=' "$name"
  cat "/proc/sys/vm/$name"
done

printf '%s\n' '=== zram and OOM policy ==='
zramctl 2>/dev/null || true
systemctl is-active systemd-oomd 2>/dev/null || true
systemctl is-active earlyoom 2>/dev/null || true

Read stored_pages using the machine’s actual base page size. Assuming 4 KiB on this ARM host would understate the logical pages by a factor of sixteen. Read pool_total_size as physical bytes used by compressed storage, not logical bytes saved.

What this snapshot cannot prove

• No synthetic pressure was induced on the production server, so the audit does not benchmark a full pool.
• Debugfs event counters are intentionally approximate under concurrent access.
• The snapshot cannot attribute swap candidates to individual processes or cgroups through this old zswap interface.
• There is no zswap-disabled or zram comparison run, so the audit cannot assign a performance gain to the current 2.75 MiB pool.
• The macOS snapshot is a separate machine and workload, so its compressor density cannot benchmark or size this Linux host.
• Upstream Linux 5.4 explains the observed interfaces, but Oracle UEK may carry additional patches; runtime behavior remains authoritative for this host.

The evidence supports a no-change decision, not a claim of optimality. Zswap is enabled, correctly backed, lightly used, and has no recorded failure events. The old kernel is the larger operational constraint, which makes a planned platform upgrade more defensible than changing the compressed-swap topology without a workload requirement.

How Linux 5.4 handles a full zbud pool