Swap and memory reclamation

A clean file-backed cache page can often be dropped because the file supplies its contents again. A dirty file-backed page ordinarily needs appropriate writeback before that physical storage can be reused without losing changes. Anonymous private state has no original file copy to reread, so reclaim may preserve it in swap if eligible and swap is available. The word anonymous does not mean unimportant; it can contain a live request, a model's mutable state, or a language runtime heap. Losing that content is not an acceptable eviction policy.

Some physical memory is unreclaimable at the moment, for example because a driver holds a relevant pin or kernel state is still actively required. Other kernel caches may be shrinkable through their own mechanisms. Reclaimability is therefore not a single property of all nonfree RAM. Before changing policies, ask which pages dominate and why they remain needed. A system can show considerable memory in caches and still be healthy because those caches are useful and can shrink; forcing them empty may only create future misses and storage traffic.

Background reclaim tries to restore free-page reserves before an allocation is forced to do substantial work itself. Under stronger pressure, an allocating task can enter direct reclaim and wait while pages are examined, written, or otherwise made available. Allocation latency can then reflect memory-management work unrelated to the tiny object the application requested. Reclaim behavior depends on the zone, node, cgroup, allocation constraints, and kernel policy. Global free bytes alone cannot prove that a particular constrained allocation is easy to satisfy.

Swap occupancy says that some eligible content has a swap representation or is accounted as swapped under the metric being read. It does not, on its own, mean that the machine is currently transferring that many bytes per second. A cold inactive page remaining swapped out can be harmless. Repeatedly swapping useful pages out and faulting them back in can destroy latency and throughput. Correlate swap-in and swap-out rates, reclaim efficiency, pressure-stall information, and useful completions. Changing a swappiness preference does not create extra device bandwidth or make anonymous and file-backed pages equally costly.

A useful experiment reduces the demand that creates churn: shrink a batch, cap concurrent workers, release no-longer-needed buffers, or move a cold phase elsewhere. Compare useful throughput and latency before and after, along with memory and storage counters. Adding swap may prevent abrupt failure yet still leave a workload too slow to serve its users. Conversely, disabling swap indiscriminately can force earlier exhaustion or evict valuable file cache. Choose a policy using a workload-specific service objective and tested recovery behavior rather than treating zero swap use as an absolute virtue.

In the queue lab, interpret arrivals as normalized requests for reclaim work and service as reclaim completion capacity. Press Reset, explicitly set both arrival two and service four, predict drainage of the initial four-job backlog in two seconds, then Play or Step. For a separate comparison, Reset, set both arrival two and service one, predict one-job-per-second growth from four, then Play or Step. Rate edits alone retain elapsed time and recompute the initial-value model. This fluid model has no clean/dirty classifier, device latency, or OOM policy. Explain why faster scanning need not free pages faster when many scanned pages remain ineligible.