A page fault is not always a storage read

Sat, 13 Nov 2027 00:00:00 +0000

A page fault means the processor could not complete an access using the current mapping or permissions. It is not synonymous with a storage read, and some faults represent invalid accesses rather than recoverable demand paging. Linux’s minor and major counters distinguish whether handling required page-in I/O. Interpret those counters alongside the mapping type and workload; neither is a direct measurement of all application storage traffic.

Minor does not mean free

A minor fault can map an already resident file page, allocate and zero anonymous memory, or copy a page for a copy-on-write mapping. The kernel may need memory allocation, page-table work, copying, and synchronization. Describing it as only adding a pointer misses those costs. A sufficiently intense minor-fault workload can consume meaningful CPU time and affect latency even without storage reads.

The first application access does not necessarily produce a fresh fault for each base page. Prefaulting, existing mappings, readahead-related mapping behavior, and large pages can change the count. The operating system’s page size is not universally 4096 bytes. An example should obtain the local value and avoid claiming an exact fault count from the number of loop iterations.

Major describes a different path

A major fault indicates handling involving page-in I/O, often for file-backed data or swapped-out memory. Storage can include devices or remote filesystems; the label is not a physical-disk latency benchmark. One fault can initiate readahead that serves later accesses, so a count is not a one-to-one count of pages or disk requests. Conversely, ordinary file reads can cause I/O without producing corresponding major faults in the application.

File-cache residency can allow a new process to incur minor faults even when it has never touched that file. A process restart is not equivalent to dropping the host’s page cache. Anonymous first-write faults commonly allocate zero-filled memory without reading old payloads from storage, but pressure and concurrent activity can still affect measurements. “Anonymous” is not a universal promise that the entire process’s major counter remains unchanged.

When it breaks

A cold-start latency spike can correlate with major faults, but do not prescribe warming before establishing what is missing. Pre-touching unnecessary pages consumes memory and can displace useful cache. Staggered starts may help a measured shared bottleneck; another workload may instead need smaller mappings, a different access pattern, or more memory headroom. Fault counts alone do not choose among these remedies.

Sustained swapping can repeatedly return evicted pages to the working set and increase latency. Adding more workers can worsen that situation by increasing memory demand. Correlate faults with swap activity, reclaim, storage waits, and request latency. A rising major count is evidence to investigate, not a verdict that the storage device is faulty or that every cache miss was avoidable.

Per-process counters also include work outside the line of code being measured. Interpreter activity, startup, and other threads can contribute. A residency probe is only a snapshot, and access immediately afterward can encounter a different state. Avoid dropping global caches or increasing a test allocation until it threatens unrelated work just to obtain a dramatic graph.

Minor faults, major faults and invalid accesses follow different paths; the anonymous-memory example does not exercise every path.

Check it quickly

Save this as fault_probe.py and run python3 fault_probe.py on Linux with Python 3.9 or newer and sufficient spare memory. It writes one byte per native page through a private anonymous mapping of sixteen MiB, then repeats the pass. The mapping is closed automatically, and no file, global cache setting, or memory limit is changed.

import mmap
import resource
import sys
import time

if not sys.platform.startswith("linux"):
 raise SystemExit("This exercise requires Linux getrusage semantics")
PAGE = mmap.PAGESIZE
SIZE = 16 * 1024 * 1024

def counters():
 value = resource.getrusage(resource.RUSAGE_SELF)
 return value.ru_minflt, value.ru_majflt

def touch(region):
 for offset in range(0, len(region), PAGE):
 region[offset] = 1

with mmap.mmap(-1, SIZE, flags=mmap.MAP_PRIVATE | mmap.MAP_ANONYMOUS,
 prot=mmap.PROT_READ | mmap.PROT_WRITE) as region:
 before = counters()
 start = time.perf_counter()
 touch(region)
 first_seconds = time.perf_counter() - start
 middle = counters()
 start = time.perf_counter()
 touch(region)
 second_seconds = time.perf_counter() - start
 after = counters()
first = tuple(b - a for a, b in zip(before, middle))
second = tuple(b - a for a, b in zip(middle, after))
print(f"page_size={PAGE} mapping_bytes={SIZE}")
print(f"first: minor={first[0]} major={first[1]} seconds={first_seconds:.6f}")
print(f"second: minor={second[0]} major={second[1]} seconds={second_seconds:.6f}")
assert first[0] > 0, "expected demand-fault activity"
assert second[0] < first[0], "repeat pass did not show reduced minor faults"
assert first[1] == second[1] == 0, "observed major faults: this run is not a no-major example"
print("PASS: this run had fewer second-pass minor faults and no measured major faults")

The test expects demand-fault activity on the first pass, fewer minor faults on the second, and no measured majors in this particular run. Those assertions passed for both exact language examples during this review. Counts and durations are observations, not fixed targets. The script does not assert that the second pass is faster; timers and scheduling can vary.

A failed assertion means this run did not establish the expected contrast. Inspect its memory conditions and counters rather than silently deleting the check. The successful result shows one anonymous-memory case where fault activity occurred without measured page-in I/O. It does not demonstrate a file-backed major fault, establish universal fault latency, or replace measurements of the real application under representative pressure.

Sources