Virtual Memory, Page Faults & Reclaim

Engineering focus: Explain virtual memory, address translation, heap versus stack, RSS versus VSZ/PSS, page faults, page cache and swapping. A node reports 95% used memory; is that necessarily bad?

2.1 Virtual addresses are not physical addresses

Each ordinary process has a virtual address space. Its addresses are translated through page tables by the CPU memory-management unit (MMU), with a translation lookaside buffer (TLB) caching frequent translations. On a TLB miss, the CPU may walk page tables; a page fault happens when an access needs kernel handling—not on every TLB miss.

Virtual-to-physical memory translation

Address Space Layout Randomization (ASLR) varies mapping locations for security. Actual layout depends on architecture, runtime, mapped libraries and thread stacks.

2.2 Stack, heap, code and mappings

• Text/code: executable instructions, frequently file-backed and shareable.
• Data/BSS: initialized and zero-initialized global/static storage.
• Heap: allocations via runtime allocator mechanisms such as brk and mmap. Heap memory isn't synonymous with every kind of process memory.
• Stacks: function execution context, local variables and per-thread stack mappings. Stack exhaustion can arise from recursion or very large local frames.
• Mapped regions: shared libraries, anonymous maps, mapped files, direct buffers and other runtime allocations.

The size of a mapping does not imply all mapped pages currently occupy RAM.

2.3 RSS, VSZ, PSS and cgroup accounting

Measurement	What it tells you	Caveat
VSZ / VIRT	Total mapped virtual address space	Reserved/untouched mappings may be huge
RSS	Physical resident pages mapped by a process	Shared pages are counted in multiple processes
PSS	Proportional resident set size	Shares cost of shared pages across mappers
USS	Private uniquely resident memory (derived)	Depends on accounting/tool
cgroup memory.current	Memory charged to the cgroup	Includes charged cache and kernel memory, not just heap

Example: an application reserves 16 GiB address space but touches 500 MiB. A 16 GiB VIRT readout does not mean 16 GiB of physical RAM consumed. For four processes sharing a 100 MiB library, summing RSS may double-count those pages; PSS gives a more useful proportional attribution.

cat /proc/4200/status
cat /proc/4200/smaps_rollup
pmap -x 4200
free -h
cat /proc/meminfo

2.4 Minor, major and invalid page faults

Minor faults can be serviced without a disk fetch: allocate a fresh anonymous page, resolve copy-on-write, or map a file page already in cache. Major faults require fetching needed page contents through an I/O path. Invalid access faults can deliver SIGSEGV and are not normal successful demand paging.

ps -p 4200 -o pid,min_flt,maj_flt,rss,vsz
pidstat -r -p 4200 1

A high minor-fault rate is not automatically a problem. Major faults correlated with latency, swapping and reclaim are more concerning.

2.5 Page cache and MemAvailable

Linux opportunistically caches file data in RAM. A file read can be satisfied by the page cache without going to storage. Buffered writes can mark pages dirty, which are written back later. Many clean cache pages are reclaimable.

Buffered file read

MemFree measures completely unused memory. MemAvailable estimates reclaimable room for new applications without swapping; neither is an ironclad guarantee. A system with only 1 GiB completely free but 7 GiB available and low memory pressure may be healthy.

free -h
vmstat 1
cat /proc/meminfo | grep -E 'MemAvailable|Cached|Dirty|Writeback|AnonPages|SReclaimable'

2.6 Reclaim, swap and thrashing

When allocations face pressure, the kernel can reclaim clean file-cache pages, write dirty pages, reclaim eligible slab objects or swap eligible anonymous memory. kswapd performs background reclaim; direct reclaim can make the allocating thread stall. Memory can therefore cause severe tail latency before any OOM event.

Thrashing occurs when reclaim and page movement dominate useful work. Correlate vmstat swap in/out (si, so), major faults, memory pressure stall information (PSI), and application p99.

vmstat 1
cat /proc/vmstat
cat /proc/pressure/memory

2.7 Heap is not the entire container footprint

A runtime may report 600 MiB heap while the container is charged 1.4 GiB. Other contributors can include direct/off-heap buffers, thread stacks, native allocations, memory-mapped files, page cache, kernel and socket buffers, and runtime metadata. Use application/runtime tools and cgroup accounting.

2.8 Production incident: 95% used memory

Two snapshots tell very different stories:

Healthy cache-heavy host	Host under memory pressure
64 GiB total; 60 GiB used	64 GiB total; MemAvailable 200 MiB
MemAvailable 21 GiB	Major faults rising
Low memory PSI	Elevated reclaim and PSI
No sustained swap	Sustained swap in/out
Stable application p99	Application p99 many times baseline

A lead engineer should not restart workloads to clear cache based on a single "95% used" chart. Demonstrate stalls, reclaim or a true memory working-set problem before intervening.

Key takeaways

Linux gives processes virtual address spaces whose pages are mapped to physical memory when needed. RSS, virtual size and cgroup memory account for different things; page cache is often beneficial and reclaimable. Distinguish anonymous allocations, file cache, major faults, swap and direct reclaim. To decide whether 95% used RAM is harmful, check MemAvailable, memory PSI, reclaim counters and application latency rather than utilization alone.