Paging

The virtual address space is divided into pages and physical memory into frames of the same size — 4 kB on x86-64 and most ARM64 Linux systems, 16 kB on Apple silicon, 64 kB on some ARM server configurations. A 4 kB page means the low 12 bits of an address are the offset within the page and never translate; only the high bits (the virtual page number) are looked up. A mapping is a page-table entry (PTE) saying "virtual page N is in frame M, with these permissions". The page is the unit of everything: allocation, protection, sharing, swapping, caching. You cannot map, protect or swap half a page.

The choice of size is a trade-off with two sides. Smaller pages waste less memory at the end of each region (internal fragmentation, at most one page per mapping) and let the kernel be finer-grained about what to load and evict. Larger pages need fewer entries — a smaller table, fewer faults to cover a region, and far more memory covered by the same number of TLB entries (The TLB). 4 kB was chosen in the 1980s when RAM was measured in megabytes; it is now widely considered too small, which is why huge pages and 16 kB defaults exist.

An entry is one machine word (8 bytes on 64-bit) that packs the frame number with a set of flag bits. The exact layout is per architecture, but the flags are universal because the kernel needs each of them for something specific.

The present bit is the pivot of the whole system: if it is clear, the CPU does not interpret the rest of the entry and raises a page fault instead, and the kernel is free to use the remaining bits to remember *why* — the page is on swap at this offset, or is part of a file mapping, or has never been touched. Every lazy mechanism in this module (Page Faults, Copy-on-Write, Memory Mapping, swap in Memory Pressure, Swap and the OOM Killer) is the kernel clearing this bit on purpose and handling the fault later.

The accessed and dirty bits are set by the CPU, not by the kernel, when the page is read or written. The kernel reads and clears them periodically to learn which pages are in use (the raw material for reclaim decisions) and which have been modified since they were last written to disk (a clean page can be dropped; a dirty one must be written first). The permission bits (writable, user-accessible, no-execute) turn a violation into a fault before it becomes a corruption: writing to code, executing the stack, or user code touching a kernel page all fault with the same mechanism.

x86-64 can map a page at three granularities: 4 kB, 2 MB (one entry in the second-lowest table level, with the PS bit set) and 1 GB. A huge page is one PTE covering 512 or 262,144 base pages — one TLB entry, one fault to materialise, one table entry to manage. For a process with a 40 GB heap the difference is 10 million entries against 20,000, and a TLB that covers 6 MB against one that covers 3 GB.

Linux offers huge pages two ways. hugetlbfs / MAP_HUGETLB reserves them explicitly at boot or runtime (vm.nr_hugepages), guaranteed and never swapped — how PostgreSQL (huge_pages = on), Oracle and DPDK use them. Transparent huge pages (THP) let the kernel opportunistically back anonymous memory with 2 MB pages and merge 4 kB pages later with khugepaged. THP is convenient and occasionally harmful: a 2 MB page is committed the moment one byte is touched (RSS inflation for sparse allocators), finding 2 MB of contiguous free frames can require compaction (latency spikes), and a copy-on-write fault copies 2 MB instead of 4 kB (Redis’s BGSAVE problem in Copy-on-Write). always vs madvise in /sys/kernel/mm/transparent_hugepage/enabled is the switch; databases document which they want.

Apple silicon and iOS use 16 kB base pages; ARM64 Linux can be built for 4, 16 or 64 kB. Code that assumes 4096 — custom allocators, memory-mapped file offsets, JIT code buffers — breaks on those systems; always ask (sysconf(_SC_PAGESIZE), os.sysconf, mmap.PAGESIZE).

Everything the kernel does "on demand" is implemented by leaving a present bit clear and catching the fault. A new mmap region has no entries at all; the first touch of each page faults, and the handler finds the region, allocates a zeroed frame, and installs the entry (What Happens When I Allocate Memory?). A mapped file’s pages fault in from the page cache or from disk (Memory Mapping). A forked child’s pages are present but read-only; a write faults and the handler copies (Copy-on-Write). A page written to swap has its entry rewritten to "not present, swap slot 4711"; touching it faults and the handler reads it back (Memory Pressure, Swap and the OOM Killer).

The fault is cheap enough to be used this way — around a microsecond when no I/O is needed — and precise enough: the CPU delivers the faulting address and whether it was a read, a write or an instruction fetch, and after the handler returns the *same instruction* re-executes as if nothing had happened. The program cannot tell that its memory was materialised, copied or fetched from disk in the middle of a load. That transparency is what makes virtual memory an abstraction rather than an API, and Page Faults follows one fault through the kernel step by step.