What Happened
Operating Systems · Performance Engineering · Hardware · Technical Reportpublished 11 Aug 2026 · record current to 3 Sep 2026
Executive summary · one-page brief
Swap Is Reclaim Fairness, Not Emergency Memory
Five platforms, one mechanism — with one exception. Anonymous memory — everything a process allocates — is the only page class a kernel cannot reclaim without somewhere to put it. So a system with no swap has not removed memory pressure; it has redirected all of it onto page cache and executable code, which are then re-read from disk again and again. Windows, macOS and Android now all answer this the same way: compress in RAM first, and touch persistent storage only when compression is exhausted. Windows calls it Memory Compression, macOS a compressor pager, Android calls it ZRAM — and a ZRAM-enabled Linux desktop does the same. Red Hat Enterprise Linux's own current documentation for creating swap describes no compression step at all: a partition or a file, nothing else. The trade, wherever compression runs, is always the same one: capacity bought with CPU cycles. What still separates the five is narrow, and only three things matter.
By the Numbers compression & endurance
- ~40%compressed footprint of a page (Windows 10, 2015)
- 2:1compression ratio the Linux kernel's own docs assume when sizing zram
- 2.4 PBwrites absorbed by the longest-surviving drive in a 2015 SSD endurance test
- 16.4 yrlife of a 600 TBW drive written 100 GB every day
The Record, Graded documentation first, device testing last
| Standing | What | How it was checked |
|---|---|---|
| Confirmed | Windows, macOS and Android all compress inactive memory in RAM before writing anything to persistent storage. | Microsoft's, Apple's and AOSP's own current documentation, read directly. |
| Confirmed | The Windows compression store uses the plain XPRESS format — not the Huffman-coded XPRESS_HUFF variant used elsewhere in Windows. | Microsoft's own Compression API reference names the two as distinct formats; a kernel-code analysis, checked against Windows Internals, names which one the memory manager uses. |
| Confirmed | A Btrfs swapfile has been supported since kernel 5.0, but only on a single-device filesystem, with the file itself uncompressed and unchecksummed. | Read directly in the Btrfs project's own documentation. |
| Confirmed — the exception | Red Hat Enterprise Linux's own current guide to creating swap names a partition or a file — no compression step at all. | Read directly; the current chapter's thirteen subsections never mention zram or zswap. |
| Confirmed, device-dependent | Which Android OEM's “extended RAM” toggle touches storage, and which only resizes ZRAM. | An adb probe of two current flagship phones — a device's own settings text does not say which it is. |
Timeline
Turning Points chronological
- 2015A long-run endurance experiment ends: six consumer SSDs are written until they fail; every one outlives its rated endurance, the first only past 700 TB.
- 2015Windows 10 inserts Memory Compression between paging activity and the pagefile, roughly halving page writes to disk.
- 2018The reclaim-fairness argument is published, reframing swap from emergency reserve to routine mechanism.
- 2018PSI merges into the Linux kernel, version 4.20, letting userspace act on stall time before the OOM killer ever runs.
- 2019Btrfs gains swapfile support in kernel 5.0, with real constraints: the file must sit on a single-device filesystem and go uncompressed.
- 2019macOS's APFS boot layout begins requiring a dedicated, hidden volume to hold swap files, from macOS 10.15 onward.
- 2020Fedora begins shipping ZRAM as the sole, default swap device from release 33, dropping disk-based swap even where hibernation would otherwise be possible.
- 2021→Android OEMs ship “extended RAM” sliders — some resize ZRAM only, others genuinely write to storage.
- 2025An adb-based test of two current flagships settles it: one maker's slider only resizes the compressed tier, the other's genuinely writes to storage.
What Has No Date honest gaps
Two things resist a date. Android OEM “extended RAM” sliders arrived phone by phone rather than on a single announced date, so the range above is the honest shape of it. Apple's own published compressor source names its algorithm mix plainly, but which macOS release that published file corresponds to is not established, nor whether the currently shipping compressor matches it exactly.
The Argument
Why Swap Still Earns Its Place prose left · figures right
File-backed pages can be dropped and re-read; anonymous pages have nowhere to go. Without swap they are simply unreclaimable, so the kernel must take every byte it needs from page cache and program text instead. That is why the strongest argument for swap is not capacity but symmetry: it makes both page classes equally eligible for reclaim, and lets the kernel evict whichever is genuinely colder. The endorsement is institutional, not rhetorical — systemd-oomd's own manual page cites this argument and states swap should be enabled for it to work well, because a swapless system reaches livelock faster and starves the very userspace killer meant to rescue it.
- 2page classes made equally reclaimable
- 4.20+kernel with PSI — pressure visible before the OOM killer
The Only Three Axes That Matter everything else is detail
| Axis | The question it asks | Why it decides the design |
|---|---|---|
| Persistent tier | Does storage-backed swap exist at all? | Some Android implementations only resize ZRAM — there is no second tier to spill into. |
| Hibernation | Can the tier hold a suspend-to-disk image? | The one hard functional dividing line: a compressed RAM tier is cleared at boot, so it never can. |
| Operator reach | How much machinery is exposed? | Windows and macOS are effectively automatic; Linux exposes the knobs; Android exposes a slider. |
Bottom line
Disabling swap does not avoid disk I/O under memory pressure — it relocates the thrashing from anonymous pages onto page cache and program text, which is usually worse.
Reframe
Sustained swap depth is a sizing signal, not a tuning problem. The fix is more RAM, not more swap.
What Others Add
Two Tiers, Five Names the shape everyone converged on
Tier one · in RAM
The Compressed Tier
- Windows Memory Compression — the plain (non-Huffman)
XPRESSformat, into a store held inside the System process. - macOS compressor pager — WKdm; what lets Apple ship lower RAM configurations at all.
- Linux ZRAM / zswap — zstd, lzo or lz4, typically around 3:1.
- Android ZRAM — always the first line of defence, before any storage is touched.
- Windows Memory Compression — the plain (non-Huffman)
Tier two · on storage
The Persistent Tier
- Windows
pagefile.sys; a separateswapfile.sysmoves a suspended app's whole working set in one I/O. - Linux partition or file — functionally equal; the file trades a filesystem mapping for flexibility.
- macOS dynamic swapfiles on a dedicated APFS VM volume, required by Apple's own boot layout since macOS 10.15.
- Android — OEM “extended RAM” sliders vary by maker: some genuinely add a UFS swapfile, others only resize the compressed tier and never touch storage.
- Windows
Platform by Platform same mechanism, different exposure
| Technology | Backend | Hibernate | Compressed |
|---|---|---|---|
| Windows pagefile | file on NTFS | separate image | yes — XPRESS, plain |
| Windows swapfile | file, modern apps only | no | yes — per-app store |
| Linux partition | raw partition | yes | no — pair with zswap |
| Linux swapfile | file on the filesystem | yes, with offset | no — pair with zswap |
| Linux ZRAM | block device in RAM | never | yes — it is the point |
| macOS dynamic swap | APFS VM volume | yes | yes — WKdm |
| Android ZRAM | block device in RAM | never | yes — lz4 / zstd |
| Android extended RAM | swapfile on UFS | no | via ZRAM first |
Where It Holds, Where It Strains four dimensions
| Dimension | Holds | Strains |
|---|---|---|
| Hibernation | a real partition or file can hold the image | a compressed RAM tier is cleared at boot — it can never substitute |
| Flash endurance | six consumer SSDs all outlived their ratings, one to 2.4 PB | low-tier eMMC and sustained server writes still need care |
| Vendor claims | probing the filesystem settles it — some do add a real tier | “8 GB + 8 GB = 16 GB” is marketing, not arithmetic |
| Mixing tiers | each tier is sound used on its own | ZRAM beside disk swap invites LRU inversion |
What the Android Slider Actually Does settled by probing, not by prose
| Behaviour | What changes when you move the slider | Cost |
|---|---|---|
| ZRAM target only | No partition and no swap area change — only how much RAM is given to the compressed tier. | CPU |
| Real storage swap | Free space on the data partition drops by exactly the requested amount, while the ZRAM pool is unchanged. | UFS writes |
| Two names, one thing | Scheduler and memory-optimisation branding is not swap; only the GB slider is. | confusion |
| Below 4 GB RAM | Genuinely useful — more background apps survive instead of being killed and reloaded. | worth it |
| 12 GB RAM and up | Rarely reached in daily use; reviewers report smoother animation with it switched off. | dropped frames |
The Endurance Question, Settled prose left · figures right
The fear that swap will wear out a drive is the most persistent objection, and it is largely answered. In the best-known long-run experiment six consumer SSDs were written until they died: the first failure came past 700 TB, and the last survivor absorbed 2.4 PB — every drive far exceeding its rated endurance. Vendors are explicit that a rated figure marks the end of warranty, not the point of failure. The arithmetic makes it concrete: a 600 TBW drive written 100 GB every single day lasts over sixteen years, and almost nobody writes that much. Two cases still deserve care — low-tier eMMC in budget phones, and servers under sustained heavy write load, which should be specified by daily-write rating rather than capacity.
- 6 / 6drives that outlived their rating
- 2cases that still warrant care
The Path a Page Takes six steps, in order
- 01Residentin RAM
- 02Compressstill in RAM
- 03Spillto disk or UFS
- 04PressurePSI reports stall
- 05Act earlyuserspace OOM
- 06Add RAMthe real fix
The Knobs That Actually Exist Linux · defaults in parentheses
| Knob | What it governs | When to move it |
|---|---|---|
| vm.swappiness (60) | How willingly anonymous memory is swapped out relative to reclaiming page cache. | Raise it above 100 when swap is faster than the filesystem, as with ZRAM. |
| vm.vfs_cache_pressure (100) | How aggressively directory and inode caches are reclaimed against page cache. | Rarely. Setting it to zero invites the out-of-memory killer. |
| vm.watermark_scale_factor (10) | When background reclaim wakes, and how much it frees once awake. | Raise it to keep more memory free on a machine prone to sudden allocation spikes. |
| ro.lmk.swap_free_low_percentage (10) | The share of free swap, as a percentage, below which lmkd treats the system as swap-starved. | Root only, per device — the in-kernel killer was removed once Linux reached 4.12. |
| ro.lmk.psi_complete_stall_ms (700) | Milliseconds of complete PSI memory stall — every task blocked at once — that triggers a critical-level kill. | Lower thresholds (down to 70ms) ship on low-RAM devices; root only. |
Conclusion
Two Postures, Not Five who decides — the vendor, or you
Windows · macOS
Leave It Alone
- Compression and spill are integrated and automatic; there is no tuning to do.
- Disabling the page file costs crash dumps and lowers the commit ceiling — a bad trade.
- On macOS, disabling swap means weakening system protections; the answer is more RAM.
- Watch the pressure indicator, not the swap figure.
Linux · Android
Choose Deliberately
- Decide the tier first — hibernation or not — then size it.
- Copy-on-write filesystems impose real constraints on a swap file; follow their own procedure.
- Pair pressure monitoring with a userspace killer, or nothing acts until the machine stalls.
- On a phone, read the slider as a background-app dial with a frame-rate cost.
Recommendations by platform
- Windows — leave the pagefile system-managed. Disabling it to reclaim a few GB forfeits crash dumps and can destabilise the machine; SSD wear is not a real consideration.
- Linux — pick one tier, not both. ZRAM at half of RAM with zstd for desktops; a real partition or file at least the size of RAM if you hibernate. Never run ZRAM beside disk swap.
- Linux servers — pair PSI with a userspace OOM daemon. Without one, the kernel killer only fires after the machine has already stalled.
- Android — enable it at 4 GB, disable it at 12 GB. Storage is orders of magnitude slower than RAM, and on a flagship the reported cost is dropped frames.
The Exception, Restated check your own distribution
Not one convention
“Compress first, spill later” describes Windows, macOS, Android, and a zram-enabled Linux desktop. It does not describe Red Hat Enterprise Linux's own current, documented default, which is a partition or a file with no compression step at all. A server built from that default has no compressed tier to hold ground before storage is touched — which is worth checking before assuming the pattern above applies to it.
Where it lands
Ask only three questions: do you need hibernation, are you mixing tiers, and is swap depth telling you to buy RAM? Everything else is detail.