Copy-on-write and fork

For eligible private mappings, parent and child can initially refer to the same physical frames through mappings that will fault on a write. On a later write, the kernel makes the writing process see a private writable page, copying the old contents when sharing requires it. A protection fault is therefore sometimes a deliberate step in implementing an otherwise legal write. The logical result matters: the parent's private variable does not change merely because the child modifies its corresponding variable. Explicitly shared mappings have different semantics and must be reasoned about separately.

Copy-on-write usually operates at a page or folio-related granularity rather than at the single byte an application intended to change. The exact split or copying behavior for huge mappings can differ from a base-page example. A small metadata update may consequently incur much more data movement than its payload suggests. A page no longer shared may be made writable without copying an entire extra frame. Avoid declaring every write fault to be a physical copy; reference state and implementation choices determine the necessary work.

Creating a child still needs execution state, kernel bookkeeping, and page-table work. A large address space with many populated mappings can therefore make fork expensive before any application page is copied. Summing parent and child resident-set sizes can count their shared frames twice. Proportional-set-size accounting apportions shared pages among their sharers and answers a different question, while cgroup accounting has its own ownership and charging rules. Choose a metric that matches whether you are budgeting host-unique physical usage, one process, or an administrative group.

A preloaded inference service may appear economical when workers only read its model. Later allocator metadata, reference counts, caches, or in-place preprocessing can dirty pages that looked immutable at the application level. Measure the actual post-fork steady state instead of assuming read-mostly high-level objects are physically unchanged. Starting an independent process with exec replaces the address space rather than preserving the inherited heap indefinitely. Process-start methods in language runtimes differ; establish which mechanism a particular deployment uses before applying a fork-based memory estimate.

In a multithreaded process, the child contains only the thread that called fork, while memory may still contain locks and runtime state left by other threads. A lock whose owning thread does not exist in the child can become a serious problem. POSIX restricts what the child of a multithreaded process can safely call before exec; use supported process-launch facilities and their documented contracts rather than attempting arbitrary allocator or logging activity in that interval. Copy-on-write addresses page ownership, not these synchronization hazards.

In the probability lab, set n to twenty initially shared pages and p to 0.25. Predict a mean of five copied pages and variance 3.75 pages squared, then raise p to 0.5 and compare the mean. The model samples no actual writes; it displays exact binomial probabilities for independent page-level copy events. Explain why writing twenty bytes packed into one page differs from writing one byte in each of twenty pages. The real workload needs a distinct-page trace, not a byte count substituted into n.