You are setting the memory policy for a fleet of Linux application servers and a colleague proposes running them all with swap disabled. What does the vm.swappiness setting actually control, and how would you decide?

## What swappiness is, and what it is not When the kernel needs free pages it can reclaim from two pools: - **file-backed pages** — page cache holding file contents, including your executables' text. Clean ones can be dropped instantly; the cost is a future major fault to read them back. - **anonymous pages** — heap, stack, private mappings. Nothing on disk backs them, so the only way to reclaim one is to write it to swap. `vm.swappiness` is the knob that biases the choice between those two pools. It is **not** a percentage of memory, **not** a threshold at which swapping begins, and **not** an enable/disable switch. Key values: - **60** — the default: a moderate willingness to swap anonymous memory. - **0** — do not swap anonymous memory unless reclaim is otherwise failing. It does not disable swap; the kernel will still swap rather than OOM-kill. - **100** — treat the two pools as roughly equal in cost. - **up to 200** — available since Linux 5.8, for cases where swap is on storage fast enough that swapping out anonymous memory is genuinely cheaper than losing cache. ```bash sysctl vm.swappiness sysctl -w vm.swappiness=10 # runtime only; persist under /etc/sysctl.d/ ``` ## The argument for turning swap off, stated fairly It is not a foolish position. The case runs: a latency-sensitive service that has been paged out is effectively down anyway, so a fast, loud OOM kill and restart beats a slow, quiet death; supervision will restart it; capacity planning should have prevented the shortage in the first place; and a swapless machine has one fewer confusing variable during an incident. ## The argument against Disabling swap does not create memory. It removes one of the two reclaim targets, and everything the kernel would have done to anonymous memory it now does to file pages instead. The practical consequences: - **Refault thrash on the wrong pages.** Under pressure the kernel evicts page cache — including the mapped text of your own binaries and libraries. The process then faults it straight back from disk. The machine crawls, CPU sits in iowait, and the swap device is untouched, so anyone who equates "memory trouble" with "swap in use" concludes memory is fine. - **Cold anonymous memory is stranded in RAM.** Every long-lived process holds start-up allocations, one-time configuration structures and idle thread stacks that are never touched again. With swap, those quietly move out and their frames become cache. Without it, they occupy premium RAM permanently. - **The failure mode becomes abrupt.** No swap means the runway between "tight" and "OOM kill" shortens dramatically, and the victim is chosen by the kernel rather than by you. ## The decision I would actually make **Default: keep a modest swap area and instrument the pressure.** Enough to absorb cold anonymous memory rather than enough to run a workload from — sizing swap to "twice RAM" is folklore from a different era. Then: - Alert on **memory stall time** from /proc/pressure/memory (`full avg10`) on kernels 4.20 and newer, never on swap occupancy. Occupancy generates permanent false alarms and teaches people to ignore memory pages. - Keep `vm.swappiness` low but non-zero (10 is a common choice) on latency-sensitive application servers: it prefers dropping cache but leaves the escape hatch open for genuinely cold anonymous pages. - Put swap on local storage, never on a network volume or a throttled cloud disk, where paging turns a slowdown into an outage. - Consider **zram** — a compressed block device in RAM used as swap, managed with `zramctl` — on memory-constrained hosts. Cold anonymous pages compress well and "paging" costs CPU rather than disk I/O. **Go swapless deliberately, in specific cases**: nodes running a workload that already manages its own memory ceiling and expects to be killed on breach; systems whose scheduler or orchestrator explicitly requires it; hosts where the only available swap device is unacceptably slow. **Either way, pin memory that must never be paged.** A process holding secrets or a latency-critical data structure should use `mlock`, which is precise, rather than depending on a machine-wide swap policy to protect it. ## How I would present it to the team The question "swap on or off" is the wrong axis, and that framing is what makes the debate perennial. The real question is *what happens when this machine runs short of memory* — how long the degradation lasts, how visible it is, and who decides which process dies. Swap changes the shape of that failure; it does not change whether it happens. Fix the shortage with capacity and with limits; use swap and swappiness to choose how the edge case degrades, and measure stall time so the choice is evaluated on evidence rather than on preference.