What Is a Page Fault?
A page fault is the interrupt a CPU raises when a program touches a page of virtual memory that currently has no mapping to physical memory.
The kernel catches that interrupt, finds or creates the page, fixes the mapping, and lets the instruction run again. The program itself never notices the detour.
The name misleads almost everyone who meets it. Nothing broke, and your operating system raises thousands of these every second on a perfectly healthy server.
Virtual memory only works because of them. The kernel promises each process a large flat address space, then backs that promise lazily. Pages arrive one at a time, as the process reaches for each address.
Minor vs Major Page Faults: What Is the Difference?
A minor page fault gets resolved from memory that the machine already holds. A major page fault has to read from disk, and that single difference decides whether the event costs you anything.
Minor fault, also called soft | Major fault, also called hard | |
Where the page already sits | In RAM, in the page cache or another process | On disk, in a file or in swap |
Disk read needed | None | One, before the program can continue |
Rough cost | Under a microsecond | 100 microseconds to 10 milliseconds |
Rate on a warm, healthy server | Thousands per second | At or near zero |
What it usually indicates | Ordinary operation | A cold start or real memory pressure |
Put those numbers next to each other and the gap explains itself. Reading a page already in RAM takes roughly 100 nanoseconds. An NVMe drive answers in around 100 microseconds, and a spinning disk needs 5 to 10 milliseconds.
So one major fault costs about a thousand RAM accesses on flash, and tens of thousands on a mechanical disk. Storage latency becomes your application's latency the moment those faults land in a hot code path.
The Third Kind Nobody Counts
An invalid fault belongs to neither group. The process reached for an address with no legal mapping behind it, usually through a bad pointer, and the kernel refuses to fix anything.
Linux answers that with SIGSEGV and a segmentation fault, and Windows raises an access violation. Both end the process rather than resuming it.
What Causes a Page Fault?
Six everyday events account for nearly all of them, and only three of the six touch a disk.
Trigger | Type | What the kernel does |
First write to freshly allocated memory | Minor | Hands over a zeroed page now, because allocation only reserved address space |
Loading a shared library another process already mapped | Minor | Points this process at the copy already in the page cache |
Writing to a page shared after a fork | Minor | Copies the page so parent and child stop sharing it |
First read of a memory-mapped file | Major | Pulls the content off disk into the cache |
Touching a page that got swapped out | Major | Reads the page back in from swap |
Reading a file page the cache evicted | Major | Fetches it from the filesystem again |
Notice how much of that list describes deliberate laziness. The kernel avoids work it might never need. A large allocation returns instantly, then costs you minor faults as the program grows into it.
When Does a Page Fault Signal a Memory Problem?
Watch the major fault rate and ignore the minor one, because only the major rate reflects memory health.
Minor faults track how busy your machine is, not how short of memory it runs. They climb whenever processes start, allocate or fork, so a deployment window produces a spike that means nothing.
Major faults on a warm server should hover near zero. Anything sustained says the working set no longer fits in RAM. The machine has started fetching pages it needs from storage.
Thrashing sits at the end of that road. Paging work grows until it crowds out the real work. Throughput collapses, and the system stays busy while achieving almost nothing.
Free Memory Can Lie to You
A host can report free memory and still take major faults. Memory limits work per cgroup (control group), so a container squeezed against its own ceiling reclaims its page cache while the host looks comfortable.
That gap catches teams out regularly. Reading major faults per container rather than per host is what container monitoring has to get right. A host-level view will never show it.
How Do You Measure Page Faults?
Linux exposes the counters five different ways, and each one answers a slightly different question.
Command | What it returns |
sar -B 1 | System-wide fault/s and majflt/s, sampled once a second |
ps -o min_flt,maj_flt,cmd -p PID | Lifetime minor and major fault counts for one process |
cat /proc/vmstat | Cumulative pgfault and pgmajfault totals since boot |
perf stat -e page-faults,major-faults COMMAND | Fault counts for a single run of one command |
vmstat 1 | The si and so columns, showing swap traffic behind major faults |
Windows splits the same job across four counters, and the naming trips people up.
Counter or tool | What it returns |
Memory\Page Faults/sec | Every fault including soft ones, so it runs high on healthy servers |
Memory\Page Reads/sec | Hard faults only, since each one represents a real disk read |
Memory\Pages Input/sec | How many pages those hard faults pulled in |
Resource Monitor, Memory tab | Hard faults per second broken out per process |
Most Windows alerts point at the wrong counter. Page Faults/sec looks alarming on any busy server because soft faults dominate it. Page Reads/sec carries the signal you actually want.
Per-process numbers matter more than the totals either way. One misbehaving service can own every major fault on a box, and process monitoring names it before you start guessing.
Page Faults and Swapping: How Are They Related?
Swapping and major page faults describe two halves of the same event. The kernel writes a page out to swap, and the next major fault on that page reads it back in.
Two columns in vmstat carry the story. The so column counts pages written to swap, and the si column counts pages read back.
Only one of those two should worry you. A burst of so on its own usually means the kernel tidied away pages nothing had touched in hours. That costs you almost nothing.
Sustained si means something wanted those pages back. Every one of them arrives as a major fault, at disk speed, while the process that asked for it waits.
How aggressively Linux swaps comes down to the swappiness setting, which defaults to 60 on most distributions. Lowering it makes the kernel prefer dropping cache over swapping application memory. That trade rarely helps once the working set genuinely exceeds RAM.
Is the Windows Page Fault Error the Same Thing?
No, the stop code named PAGE_FAULT_IN_NONPAGED_AREA describes a different failure entirely, despite sharing the words.
Ordinary page faults happen in user mode and get fixed silently. That stop code fires when kernel-mode code references an address with no valid mapping that cannot be paged in. Windows halts rather than continuing in a corrupt state.
The usual causes sit in hardware and drivers. Faulty RAM produces it, and so does a failing disk holding the paging file, or a driver writing outside its own memory.
Treat the two as separate signals. A climbing major fault rate points at capacity planning. A bugcheck points at a component that needs replacing or a driver that needs rolling back.
Keeping Fault Rates Visible
Fault counters rarely appear on a default dashboard, which is how memory pressure stays invisible until something times out. Adding major faults per host and per process to server performance monitoring costs one metric. It repays that the first time a slow service turns out to be paging.
Pair the counter with free memory and the swap-in rate. Those three together separate a genuinely undersized machine from one that simply started cold. We have closed plenty of memory tickets on that evidence alone.
Explore More IT Terms
Browse our comprehensive IT glossary to learn more about technology terminology.