Swap gives Linux a backing store for eligible memory pages that need not remain resident. It can preserve cold data while RAM serves active work, but it does not make the machine’s working set fit at RAM speed. The useful question is whether reclaim frees space without repeatedly stalling important tasks. Swap occupancy, swap traffic, and application progress answer different parts of that question.

Know which pages can move

Anonymous memory commonly uses swap, but it is not the only case. tmpfs and shared-memory pages can also be swapped when their configuration permits it. Clean pages backed by ordinary files can usually be discarded and reread from those files; dirty file pages need suitable writeback. Not every allocation is reclaimable, and memory locked against paging has another constraint. “Everything from malloc” is not an adequate description of what the kernel can move.

vm.swappiness expresses the relative cost of swapping and filesystem paging on a documented scale from zero to two hundred. It is not the percentage of RAM that triggers swap. Zero does not universally disable swapping. Values above one hundred can make sense when compressed or faster swap is cheaper than filesystem paging, but the appropriate value depends on the workload and storage. Inspect the actual configuration before interpreting a graph.

zram supplies a compressed RAM block device that can be configured as swap. zswap is a compressed cache for swap pages with a backing swap device. Compression consumes RAM and CPU, and its effectiveness depends on the data. Neither offers a universal latency, compression ratio, or safe overcommit percentage. zswap is not a filesystem to mount on /tmp; a tmpfs mount has its own storage and capacity semantics.

When it breaks

Repeatedly reclaiming pages that are immediately needed again can cause severe stalls. Storage latency and throughput may matter, but so can reclaim work, compression cost, cgroup limits, and competing I/O. Thrashing is not guaranteed to end in an OOM kill, and a fixed swap rate is not a universal diagnosis. Compare memory pressure with useful throughput and response times before assigning the cause.

A large used-swap number can reflect cold pages left there after an earlier event. It does not prove active distress. Conversely, little swap traffic does not prove enough memory: swap may be disabled, a workload may hit a cgroup limit, or reclaim may be dominated by file pages. A rising major-fault count includes file-backed faults and cannot be relabeled as a count of swap-ins.

An intended swap file can fail activation because of unsupported layout or filesystem restrictions. Files with holes are unsuitable, but whether copying creates holes depends on the tool, options, and source. Read the active swap inventory rather than assuming a configuration entry succeeded. Do not activate, resize, or disable swap on a live machine merely to reproduce a diagnostic note.

Eligible pages, swappiness, zram and zswap lead to three separate observations: swap occupancy, interval traffic and PSI stalls. Cumulative major faults do not equal swap-ins. No article example was run for this graphic.
Swap occupancy alone does not establish current pressure; interval traffic and PSI quantify different aspects of activity and stalls.

Check it quickly

Run these read-only commands on Linux with util-linux and procps installed. The check observes the current environment for three intervals; it creates no memory pressure and changes no kernel settings. A host with no active swap is a valid observation, not a failed test:

set -eu
swapon --show
free -h
vmstat -y 1 3
grep -E '^(pswpin|pswpout|pgmajfault) ' /proc/vmstat
if test -r /proc/pressure/memory; then
    cat /proc/pressure/memory
else
    printf '%s\n' 'memory PSI is unavailable in this environment'
fi

swapon --show lists active swap areas. free separates memory and swap totals. With vmstat -y, the initial since-boot report is omitted, so the three rows describe sampling intervals. Read the displayed units and compare swap-in and swap-out activity with blocked tasks and CPU time. The cumulative counters from /proc/vmstat are a separate snapshot, not rates for those exact three rows.

Memory PSI, when available, reports time lost to memory stalls. Its some and full lines distinguish at least some stalled work from simultaneous stalls of all non-idle tasks in the measured scope. A short quiet sample cannot exclude an earlier spike. Container visibility and cgroup boundaries also matter; host-wide counters do not automatically describe one application’s allocation budget.

This check verifies observation and interpretation, not storage performance, safe swap sizing, or OOM recovery. Preserve timestamps and compare a representative incident window with application latency and resource limits. If the evidence shows persistent working-set pressure, reduce demand or provide suitable capacity. Tune reclaim policy only with a reversible plan and measured service outcomes, rather than chasing zero swap usage as an end in itself.

Sources

  • Kernel VM sysctls, relative I/O cost and zero-value behavior, checked 2026-10-15.
  • Kernel tmpfs, swap-backed tmpfs and mount limits, checked 2026-10-15.
  • Kernel zram, compressed block device and storage accounting, checked 2026-10-15.
  • Kernel zswap, compressed swap cache and backing-store relationship, checked 2026-10-15.
  • Kernel PSI, memory stall scope and averages, checked 2026-10-15.
  • vmstat(8), interval reports and swap-rate fields, checked 2026-10-15.
  • proc_vmstat(5), separate swap and major-fault counters, checked 2026-10-15.
  • swapon(8), active inventory and swap-file restrictions, checked 2026-10-15.