Swap · XB Field Notes

Swap gives memory a slow extra layer

Wed, 25 Nov 2026 00:00:00 +0000

Swap is not extra memory. It is a bet: the kernel picks pages it predicts will not be needed soon, writes them to a device, and frees the RAM. When the prediction holds, a spike passes without killing a process. When it does not, every wrong guess costs a device round trip, three to five orders of magnitude above reading RAM.

The trade only works as a valve. Sizing swap to cover a chronically under-provisioned workload buys a machine that is slow in a way that looks like a CPU problem; the first question is how much of the working set does not fit.

Reclaim picks victims by prediction

Anonymous pages, the heap, the stack and anything malloc handed out, have no file behind them, so they are the only thing swap holds. File-backed pages do not need swap: the kernel can drop a clean page-cache entry and read it back later. vm.swappiness is documented as the rough relative IO cost of swapping versus filesystem paging, on a scale from 0 to 200 with a default of 60. At 0 the kernel will not initiate swap until free plus file-backed pages fall below the zone’s high watermark, so 0 means “only under duress”, not “no swap”.

Internally the dial becomes a scan weight: swappiness for the anonymous list, 200 - swappiness for the file list. Values above 100 are not a mistake: the documentation suggests 133 when random IO against the swap device is about twice as fast as filesystem IO, and recommends beyond-100 values for in-memory swap such as zram or zswap.

The price is a device round trip

Latencies tell the story: roughly 100 ns for a resident DRAM page, single-digit microseconds for compressed swap in RAM, 100 us on NVMe, 250 us on SATA SSD, 8 ms on a spinning disk. A swap-in is a thousand times a RAM hit on NVMe and eighty thousand times on a disk, and the bill is charged per page needed again.

Model 100,000 page-sized accesses per second over an 8 GiB working set: fitting in RAM, the average is 100 ns with no major faults; at 2% over, 2.1 us, twenty-one times worse; at 20% over, 16.8 us, 167 times worse, with 16,667 major faults per second and 67 MB/s through si and so. The cliff begins at the first page that does not fit.

Thrashing is a device saturation problem

The same 20% overcommit is unremarkable on compressed swap, absorbable on NVMe, and fatal on a spinning disk. A 7,200 rpm disk serves on the order of 150 random IOPS, so 16,667 faults/s cannot be met; the shortfall is never served and the wait queue grows until the OOM killer. This is thrashing: a queueing failure, not a slow-memory failure.

zram and zswap change the cost model, not the principle. zram serves a fault from compressed RAM in microseconds instead of a device round trip, which is why the documentation suggests swappiness above 100. It expects roughly a 2:1 compression ratio, so making a device larger than twice memory buys little. The two sit in different places: zram is the swap device itself, with compressed pages staying in RAM; zswap is a compressed cache in front of a real swap device, evicting to it on an LRU basis when its pool hits its size limit. zram moves swap into memory; zswap only defers the write. Both make /tmp a natural use case, where swap and temp directories stop being separate problems: both are RAM with a cap.

When it breaks

Thrashing presents as a machine busy and idle at once. The load average climbs while CPU utilisation stays low, si and so climb, and major faults dominate. Every process progresses at a fraction of its normal rate while the box is not CPU-bound, which is why this gets misdiagnosed as an application problem. Confirm with vmstat 1: sustained si/so in the thousands of KiB/s alongside a rising run queue and idle CPU is the signature.

The second failure is swap that was never attached. swapon(8) documents that the kernel writes to the swap file directly, without the filesystem’s help, so a file with holes is rejected; truncate and cp both produce one. The same page documents -e/--ifexists and nofail, which silently skip a device that is not there, so a host can boot with no swap, look healthy until the first spike, and OOM-kill something important. Read /proc/swaps rather than trusting /etc/fstab.

Check it quickly

swapon --show
free -h
vmstat 1 5
grep -E 'pswpin|pswpout|pgmajfault' /proc/vmstat

swapon --show should list a device with a nonzero size; empty output means nothing is attached. In vmstat, si and so should sit near zero; sustained thousands of KiB/s with us plus sy low is thrashing rather than load. A climbing pgmajfault means pages are coming back from the device; a flat counter means the working set is resident.

Sources

swapon(8), swap priority, discard policies, and why a sparse swap file is rejected, checked 2026-09-16.
Kernel sysctl vm documentation, swappiness as a 0-200 relative IO cost dial with the zram guidance, checked 2026-09-16.
Kernel zram documentation, compressed RAM block devices, the expected 2:1 ratio, and the /tmp use case, checked 2026-09-16.
Kernel zswap documentation, the compressed swap cache in front of a backing device and its LRU eviction, checked 2026-09-16.

zram squeezes swap into RAM

Tue, 24 Nov 2026 00:00:00 +0000

When memory tightens, cold pages would go to a slow disk. zram keeps them in compressed RAM instead, trading a little CPU for much more headroom.

A compressed block device in memory

zram is a block device that lives in RAM and stores compressed data instead of talking to a real disk. When the kernel swaps a page into it, the page is compressed and kept in memory, so the memory gain comes from shrinking the pages rather than moving them to slow storage. Because the device is memory-backed, it answers reads and writes far faster than a disk-backed swap, but the space it provides is limited by how compressible the pages are and by how much memory you are willing to trade for the swap.

Compression is the space win

Compression is the space win, and it is the reason a small box can appear to hold more memory than it physically has. Whether a page pays off depends on its content: text, zeroed pages and structured data compress well, while already-compressed blobs such as media or archives barely shrink. The honest engineering view is that zram turns spare CPU cycles into apparent memory, so the trade is worthwhile when the workload leans compressible and the extra latency of a real disk swap is exactly what you want to avoid.

It suits gove boxes and phones

The fit shines on hosts with little memory and modest I/O, such as a small VPS, a container host, or a compact device like a phone or an embedded box. It is less obviously right for a server that already has plenty of RAM or that swaps into genuinely cold storage anyway, because a real disk bought with the same spend can hold far more. The practical check is to watch the compression ratio and swap usage, decide whether swapping beats killing the process, and pick zram when resident data stays small and compressible enough to make the CPU cost a fair trade.

When it breaks

A ratio that never arrives is the commonest failure. Photos, video, encrypted buffers, and archives barely shrink, so mm_stat shows orig_data_size just above compr_data_size while swap still fills. The pool and its metadata consume RAM yet add almost no headroom, so the OOM killer fires nearly as if zram were absent.

The wrong compressor fails through CPU, not capacity. A heavy algorithm on a small VPS or old handset makes every swap-out burn cycles, so kswapd spins, system CPU climbs with pressure, and tail latency collapses before swap fills. Prefer fast choices such as lzo-rle, lz4, or low-level zstd on interactive hosts, and change only after measuring under load.

Running zswap with zram compresses twice for no gain. zswap holds its own compressed pool, then hands already-shrunk pages to zram, which finds little left to save. CPU burns on both paths while swap looks used with small effective capacity. Use one layer: zram as swap, or zswap before disk, never both.

A hard-coded disksize goes stale after any resize. A unit that pins 2 GiB still offers 2 GiB after the instance grows to 32 GiB, wasting headroom; copied to a tiny edge box, the same file reserves half of RAM and hastens OOM. The size is fixed at mkswap time, so express it as a fraction of RAM at boot.

Check it quickly

Save the following as zram_ratio.py and run python3 zram_ratio.py. It uses only the standard library, opens /sys/block/zram*/mm_stat read-only, and needs no privileges. Without those files it prints SKIP and demonstrates the same ratio math on a small example instead.

#!/usr/bin/env python3
"""Read-only zram compression-ratio check (stdlib only)."""
import glob
from pathlib import Path


def parse_mm_stat(text):
 parts = text.split()
 if len(parts) < 2:
 raise ValueError("mm_stat needs at least orig and compr fields")
 orig = int(parts[0])
 compr = int(parts[1])
 rest = [int(x) for x in parts[2:]]
 return orig, compr, rest


def report(device, orig, compr):
 if compr <= 0:
 print("%s: orig=%d compr=%d ratio=n/a (empty)" % (device, orig, compr))
 return
 ratio = orig / compr
 saved = 100.0 * (1.0 - compr / orig) if orig > 0 else 0.0
 print("%s: orig=%d compr=%d ratio=%.2f saved=%.1f%%" % (device, orig, compr, ratio, saved))


def main():
 paths = sorted(glob.glob("/sys/block/zram*/mm_stat"))
 if not paths:
 print("SKIP: no /sys/block/zram*/mm_stat found (zram absent? non-Linux?)")
 orig, compr = 300 * 1024 * 1024, 100 * 1024 * 1024
 print("worked example with the same formula:")
 report("example/zram0", orig, compr)
 print("PASS: ratio math works; on a zram host the live lines above replace the example")
 return
 for path in paths:
 try:
 text = Path(path).read_text(encoding="utf-8")
 except OSError as exc:
 print("SKIP: unreadable %s (%s)" % (path, exc))
 continue
 try:
 orig, compr, _ = parse_mm_stat(text)
 except (ValueError, IndexError) as exc:
 print("SKIP: unparsable %s (%s)" % (path, exc))
 continue
 device = path.split("/mm_stat")[0]
 report(device, orig, compr)
 print("PASS: live mm_stat accounting shown; falling ratio plus full pool means resize or recompress")


if __name__ == "__main__":
 main()

On a zram host it prints one line per device with original bytes, compressed bytes, the compression ratio, and memory used, so falling ratios and a full pool are visible before OOM. On macOS or a container without zram* it prints SKIP plus the worked example. The script passed on macOS without /sys. It checks accounting and arithmetic only, not which algorithm or disksize is correct, so confirm those in the unit files before tuning.

Sources

kernel.org: zram block device, the authoritative zram documentation, checked 2026-11-23.
Wikipedia: zram, what zram is and how it works, checked 2026-11-23.
ArchWiki: Zram, practical setup and tuning, checked 2026-11-23.

Swap · XB Field Notes

Swap gives memory a slow extra layer

Reclaim picks victims by prediction

The price is a device round trip

Thrashing is a device saturation problem

When it breaks

Check it quickly

Sources

zram squeezes swap into RAM

A compressed block device in memory

Compression is the space win

It suits gove boxes and phones

When it breaks

Check it quickly

Further reading

Sources