Standard swapping, as we've seen, treats processes as monolithic units: entirely in memory or entirely on disk. Paging, by contrast, divides memory into fixed-size pages that can be individually managed. When we combine these concepts, we get page-level swapping—the technique used by virtually all modern operating systems.

In page-level swapping (often called demand paging when combined with lazy loading), individual pages can reside in memory or on swap space. A process runs with some pages in RAM and others on disk, loading pages on demand as they're accessed. This approach dramatically improves memory utilization, reduces swap I/O, and enables optimizations like copy-on-write and memory-mapped files.

This page explores how swapping and paging integrate, the mechanisms that make page-level swapping work, and the sophisticated optimizations that modern systems employ.

Demand paging is the cornerstone of modern memory management. Instead of loading an entire process into memory at start-up, pages are loaded on demand—only when first accessed. This lazy approach has profound implications for system efficiency.

How demand paging changes program startup:

Consider starting a large application like a web browser:

Without demand paging (standard swapping era):

1. Allocate memory for entire executable (500MB)
2. Load all code and data from disk
3. Initialize all data structures
4. Only then can execution begin
5. Startup time: 5-10 seconds

With demand paging:

1. Create page table entries marked 'not present'
2. Load only the first few code pages needed for main()
3. Begin execution immediately
4. As code branches run, their pages fault in
5. Unused features (e.g., print dialog) may never load
6. Startup time: <1 second

The difference is transformative. Most programs never execute all their code paths in a typical session—demand paging ensures unused code never consumes memory or I/O.

A critical distinction in page-based swapping is between anonymous pages and file-backed pages. This classification determines how pages are handled during memory reclaim.

Why this distinction matters for swapping:

Consider the memory reclaim algorithm's decisions:

File-backed clean pages are the cheapest to reclaim—no I/O needed at all. This is why systems often favor caching executables and libraries: they can be evicted instantly if memory is needed.

Linux's approach:

Linux maintains separate LRU (Least Recently Used) lists for anonymous and file-backed pages. The vm.swappiness parameter (0-200) controls the balance:

• swappiness = 0: Strongly prefer evicting file-backed pages; only use swap as last resort
• swappiness = 60 (default): Balance between file and anonymous reclaim
• swappiness = 100: Equal preference for file and anonymous reclaim
• swappiness = 200: Aggressively swap anonymous pages

# View current swappiness
cat /proc/sys/vm/swappiness

# Reduce swappiness for database workloads (prefer file cache eviction)
echo 10 > /proc/sys/vm/swappiness

Copy-on-Write (CoW) is a critical optimization enabled by paged memory management. It allows processes to share physical pages until one process writes, at which point a private copy is made. This technique deeply integrates with swap management.

How Copy-on-Write works:

1. Fork creates shared mappings — When a process forks, the child doesn't copy parent memory immediately. Instead, both processes' page tables point to the same physical frames.

2. Pages marked read-only — Even for originally writable memory, CoW pages are marked read-only in both page tables.

3. Write triggers fault — When either process tries to write, a protection fault occurs.

4. Fault handler makes copy — The kernel allocates a new frame, copies the original content, maps the new frame to the writer, and marks both the old and new frame writable.

5. Original frame may have other sharers — Reference counting tracks whether a frame is still shared or can be reclaimed.

CoW and swap interaction:

Copy-on-write pages present special challenges for swap management:

Shared swap slots:

• When a CoW page is swapped out before either process writes, both processes share the same swap slot
• Swap slot reference counts track this sharing (similar to frame reference counts)
• If one process swaps the page back in and writes, CoW resolution creates a new frame, but the swap slot may still be referenced by the other process

Swap entry sharing:

Page P is CoW-shared by processes A and B
Memory pressure: P is swapped out to slot S
  - A's PTE: swap entry pointing to slot S
  - B's PTE: swap entry pointing to slot S
  - Slot S reference count: 2

Process A accesses the page:
  - Page fault, swap-in from slot S
  - New frame F allocated, content loaded
  - A's PTE: points to F, marked CoW (still shared)
  - B's PTE: still swap entry to S
  - Slot S reference count: 1 (only B references it now)
  - Frame F: marked CoW, A and 'swap' are 'sharers'

Process A writes to the page:
  - CoW fault, copy made (but this is first copy after swap-in)
  - A gets exclusive writable frame

Process B accesses the page:
  - Swap-in from slot S
  - B gets frame with original content
  - Slot S freed (ref count = 0)

This intricate dance ensures that CoW semantics are preserved even when pages transit through swap.

Beyond loading pages from files or swap on demand, modern systems apply laziness to initial memory allocation as well. When a process allocates memory (e.g., via malloc() for large allocations or mmap()), the kernel typically doesn't allocate physical frames immediately. Instead, it uses zero-fill-on-demand (ZFOD).

The zero page optimization:

Linux and other systems maintain a special zero page—a single physical frame filled with zeros, mapped read-only. When a process reads from never-written anonymous memory, it gets the zero page:

• Memory: 1GB allocation with only 10MB written
• Zero page mappings: 99% of pages (read-only, shared)
• Private frames: 1% of pages (the 10MB actually written)

This creates an interesting swap scenario: pages that have never been written don't need swap space at all. They're regenerated as zero pages when needed.

Swap and lazy allocation:

When memory pressure hits:

1. Never-touched pages — No swap needed; they're just zero-fill-on-demand. The page table entry is simply cleared.

2. Touched but unchanged pages — If a page was touched but remains all zeros, some systems detect this (page content checks) and treat it as never-touched.

3. Modified anonymous pages — These must go to swap; their content can't be regenerated.

With page-based swapping, the system must decide which pages to evict when memory is needed. This is the page replacement problem, and the choice of algorithm significantly impacts performance.

The optimal algorithm (Bélády's MIN):

The theoretically optimal page replacement algorithm evicts the page that will be accessed furthest in the future. Unfortunately, this requires knowing future memory accesses—impossible in practice. However, it serves as a benchmark against which other algorithms are measured.

LRU (Least Recently Used):

The most intuitive practical approximation of optimal is LRU: evict the page that was accessed longest ago. The intuition is that recent access patterns predict future access: pages not used recently are unlikely to be used soon.

True LRU requires updating a timestamp on every memory access—too expensive. Real systems use approximations.

Linux's multi-generational LRU (MGLRU):

Introduced in Linux 6.1, MGLRU improves upon the traditional active/inactive lists by using multiple generations to more accurately track page age:

• Youngest generation — Recently accessed pages
• Older generations — Pages not accessed in recent time intervals
• Oldest generation — Eviction candidates

Pages age through generations over time. Access resets a page to the youngest generation. This provides finer-grained age tracking than binary active/inactive, better approximating true LRU.

Working set considerations:

The ideal behavior is to keep each process's working set (pages actively in use) in memory. When memory can hold all working sets, page faults are rare. When working sets exceed memory, thrashing occurs: constant page faults as processes fight for frames.

Linux's page reclaim considers working set size when deciding how aggressively to reclaim from a process. Processes with rapidly shrinking access patterns are good eviction targets; those with stable, large working sets are protected.

Memory-mapped files (mmap()) create a direct mapping between a file and virtual address space. This technique leverages paged memory management and interacts with swap in specific ways.

How mmap interacts with swap:

Key insights:

1. Shared file mappings never use swap — They write back to the file. The file is the backing store.

2. Private file mappings have split behavior — Unmodified pages discard to file. Modified (CoW) pages are now anonymous and use swap.

3. Anonymous mappings always need swap — There's no file backing. This is mathematically equivalent to reading/writing a temporary file, but more efficient.

The page cache connection:

File-backed memory mappings go through the page cache—the kernel's cache of file contents. The same physical frames back both mmap'd regions and regular read()/write() access to files. This means:

• Reading a file via mmap uses the same cache as read()
• Memory pressure that evicts cached file pages affects mmap performance
• mmap'd database files benefit from the kernel's LRU page management

Modern kernels employ sophisticated page reclaim subsystems that orchestrate swapping and cache eviction. Understanding these internals helps diagnose memory pressure issues and tune system behavior.

Linux memory reclaim overview:

Linux's memory reclaim operates at multiple levels:

Allocation Request
        ↓
  Free pages available? ──Yes──→ Satisfy from free list
        ↓ No
  Direct reclaim (synchronous)
        ↓
  Activate kswapd (asynchronous)
        ↓
  Scan LRU lists
        ↓
  Evict/swap pages
        ↓
  Still short? Try harder
        ↓
  OOM killer (last resort)

Key components:

1. kswapd — Per-NUMA-node kernel thread that wakes when free memory falls below watermarks. It runs in the background, reclaiming pages to maintain a buffer of free memory.

2. Direct reclaim — When allocation fails despite kswapd's efforts, the allocating process itself performs synchronous reclaim. This adds latency to the allocation.

3. Watermarks — Three thresholds control behavior:

   • High watermark: kswapd stops reclaiming
   • Low watermark: kswapd wakes up
   • Min watermark: Emergency reserve for critical allocations

4. Priorities — Reclaim scans LRU lists with increasing intensity. Early scans are gentle; later scans become more aggressive as desperation increases.

Page-based swapping transforms memory management from coarse process-level operations to fine-grained page management. This approach enables efficient memory utilization, sophisticated sharing, and graceful degradation under pressure.

What's next:

We've explored how swapping integrates with paging. The final topic—performance considerations—examines the practical impact of swapping on system performance: measuring swap activity, identifying pathological patterns, and tuning systems to balance memory utilization against responsiveness.