Copy-on-Write

The insight is that a copy is only observable when one side writes. Until then, two processes reading the same bytes might as well read the same frames. So fork copies the page tables, not the pages: the child gets its own tables whose entries point at the parent’s frames, every writable private page is marked read-only in *both* tables, and each frame’s reference count is incremented. The child is a complete, independent process — its own PID, its own address space in the sense that matters (Creating Processes: fork, exec, wait) — that happens to share all of its physical memory with its parent.

The cost of the fork is therefore proportional to the *size of the page tables*, not to the memory: about 2 MB of tables per GB of 4 kB mappings, which the kernel walks and duplicates. A 10 GB process forks in tens of milliseconds rather than seconds; a 100 MB process forks in well under a millisecond. Pages that were already read-only (code, shared libraries) need no marking and are shared exactly as they were before.

Now the child stores to a heap page. The PTE says read-only; the CPU raises a page fault with "write, user" in the error code (Page Faults). The handler finds the region and sees it is *supposed* to be writable — this is not a permission violation but a CoW page. If the frame’s refcount is greater than one, it allocates a new frame, copies 4 kB into it, points the child’s PTE at the copy with write permission, decrements the original frame’s refcount, and returns; the store re-executes into the private copy. If the refcount was already one (the other side has since copied or exited), it simply flips the PTE to writable — no copy at all. Either way the parent’s view is untouched.

The divergence is incremental and lazy. A child that touches 1% of its pages has 1% of the memory copied; a child that immediately calls exec copies nothing, because exec discards the whole address space before any write. That was the case the design targeted: the shell forks and execs a thousand times a minute, and each fork must cost microseconds. vfork and posix_spawn go further by not even copying the page tables (the child borrows the parent’s memory until exec), and are what modern runtimes use to spawn processes — Python’s subprocess uses vfork or posix_spawn where it can since 3.8/3.11.

Process creation is the origin: every fork on every Unix since the 1980s. Snapshots are the modern star. Redis’s BGSAVE forks; the child walks the *entire* dataset and writes it to the RDB file while the parent keeps serving writes, and copy-on-write guarantees the child sees a consistent point-in-time image at zero cost for pages the parent does not touch. The same trick gives a forking database a consistent snapshot for a backup, a test framework a pristine process state to reset to, and Android its zygote: one warmed-up JVM process forked for every app so that framework classes are shared across all of them.

The kernel uses it internally too: the zero page is a single all-zero frame mapped read-only into every untouched anonymous page, so reading fresh memory costs nothing and the first *write* allocates. MAP_PRIVATE file mappings (Memory Mapping) — every executable’s data segment — are CoW against the page cache. KSM (kernel same-page merging) finds identical pages across VMs and merges them CoW to overcommit hypervisor RAM.

And a historical note from user space: before C++11, libstdc++’s std::string was copy-on-write — copies shared a buffer with a reference count and copied on the first mutating call. C++11 effectively banned it (a [] on one copy must not invalidate references in another, and the refcount was a data race under threads), and modern strings copy eagerly with a small-string optimisation instead. Persistent data structures in functional languages, Git’s object store and btrfs/ZFS snapshots are the same idea applied to trees and blocks rather than pages.

A fork costs the page-table copy (tens of ms for 10 GB) plus, afterwards, one minor fault and one 4 kB copy — roughly a microsecond — per page written by *either* side. That last word is the trap. In the Redis case the *parent* is the one writing: a write-heavy workload touches many pages during the seconds the child takes to serialise, and each touch copies a page, so memory usage climbs towards double the dataset and the parent’s latency carries a fault per first-touched page. With transparent huge pages enabled the unit is 2 MB, so a single 8-byte write copies half a megabyte; Redis’s documentation tells you to disable THP for exactly this reason, and reports latest_fork_usec so you can see the page-table cost.

Fork in a multi-threaded process is a separate hazard: only the calling thread exists in the child, and any lock another thread held at that instant is held forever in the child — including the allocator’s. That is why fork followed by anything other than exec is unsafe in threaded programs, why Python 3.12 warns about it, and why runtimes moved to posix_spawn. Finally, CoW makes memory accounting non-obvious: two processes sharing 10 GB each report 10 GB RSS, and the machine may or may not be able to afford both writing.