Fundamentals 41 min read

How Linux Handles Page Faults: Inside Virtual Memory Management

This article explains Linux page faults, describing how the kernel intercepts invalid or unmapped memory accesses, the step‑by‑step handling process, the four typical fault scenarios, and optimization techniques, while providing code examples and diagrams to illustrate virtual‑memory management in depth.

Deepin Linux
Deepin Linux
Deepin Linux
How Linux Handles Page Faults: Inside Virtual Memory Management

1. Page Fault: Core of Virtual Memory Management

1.1 What is a page fault?

In Linux, a page fault (Page Fault) occurs when a process accesses a virtual address whose corresponding physical page is not present in memory. The CPU triggers a hardware exception, and the kernel intervenes to either load the required page or terminate the process.

Page faults are typically triggered in two situations:

Program accesses an illegal address (e.g., out‑of‑bounds or freed memory).

Address is valid but the physical page has not yet been allocated.

Functions such as malloc() and mmap() only create virtual address space; when the process first accesses that space, the CPU automatically raises a page fault.

The handling of a page fault follows four main steps:

Save the CPU context (registers, program counter).

Analyze the cause of the fault.

Enter the kernel's page‑fault handler.

Restore the CPU context and resume execution.

2. Four Typical Scenarios that Trigger Page Faults

2.1 Page not loaded: lazy loading

When a process first accesses a newly allocated virtual address (e.g., after malloc), the kernel performs a request‑page operation: it locates the data on disk (or zero‑fills an anonymous page) and maps the physical page, allowing the process to continue.

2.2 Page swapped out: memory pressure

If physical memory is exhausted, the kernel swaps out rarely used pages to the swap partition. Subsequent accesses to those pages cause a "major fault" that reads the page back from disk, which is far more expensive than a minor fault.

2.3 Write‑protect conflict: Copy‑on‑Write (COW)

When multiple processes share a read‑only page (e.g., after fork), a write attempt triggers a page fault. The kernel allocates a new physical page, copies the data, and updates the page table so the writing process gets a private writable copy.

2.4 Illegal access: memory safety guard

Accesses to unmapped or protected regions (null pointer dereference, kernel‑space access from user mode) cause a fault that the kernel resolves by sending a SIGSEGV signal, terminating the offending process.

3. Complete Handling Flow from Hardware to Kernel

3.1 Hardware layer: MMU exception capture (ARMv7‑A example)

The MMU translates virtual to physical addresses. If the page table entry is invalid, the MMU raises a Data Abort exception, saving the faulting address and jumping to the exception vector.

3.2 Kernel layer: three‑stage processing

(1) Legality check : The kernel reads the fault address, looks up the VMA, and determines whether the access is legal. Illegal accesses result in SIGSEGV.

(2) Page‑load strategy : For legal faults, the kernel decides whether to allocate a new anonymous page, read data from a file, or bring a swapped‑out page from disk.

(3) Page‑table update and context restore : After loading the page, the kernel updates the page‑table entry (sets the valid bit, permissions, and PFN) and resumes the faulting instruction.

4. Minor vs. Major Faults: Performance Impact

Minor faults involve only memory operations (allocation or COW) and typically cost 1‑10 µs. Major faults require disk I/O, costing 1‑10 ms, and can severely degrade system performance when frequent.

5. Optimization Strategies

5.1 Program‑level optimizations

Use data locality (arrays over linked lists) and large pages (via mlock() or kernel huge‑page settings) to reduce page‑fault frequency. Tools like AddressSanitizer ( -fsanitize=address) help catch illegal accesses early.

5.2 System‑level tuning

Adjust vm.swappiness to lower swap aggressiveness, lock critical memory with mlock(), and monitor faults using perf stat -e page-faults, vmstat -s, or dmesg | grep -i page.

5.3 Hardware upgrades

Increasing physical RAM, using NVMe SSDs, and enabling Transparent Huge Pages (THP) can dramatically cut major‑fault latency.

6. Practical Example: Page Fault from malloc

6.1 User‑space program

#include <stdio.h>
#include <stdlib.h>

int main() {
    char *ptr = (char *)malloc(1024 * 1024);
    if (!ptr) { perror("malloc"); return 1; }
    printf("Allocated address: %p
", (void *)ptr);
    ptr[0] = 1; // first access triggers a page fault
    free(ptr);
    return 0;
}

The first write to ptr[0] causes the MMU to detect an invalid page, raise a fault, and the kernel allocates a physical page, updates the page table, and resumes execution.

6.2 Kernel log analysis

[ 1234.567890] page allocation failure: order:0, mode:0x20(GFP_KERNEL)
[ 1234.567890] handle_pte_fault+0x418/0x8a0
[ 1234.567890] handle_mm_fault+0x524/0x820
[ 1234.567890] do_page_fault+0x204/0x460

The log shows the allocation path taken by the kernel when handling the fault.

Page fault handling diagram
Page fault handling diagram
Page table entry fields
Page table entry fields
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Memory ManagementlinuxVirtual MemoryOperating SystemPage Fault
Deepin Linux
Written by

Deepin Linux

Research areas: Windows & Linux platforms, C/C++ backend development, embedded systems and Linux kernel, etc.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.