How Copy-on-Write Optimizes Linux Process Creation

TL;DR — Linux’s copy‑on‑write (COW) strategy lets fork() duplicate a process almost instantly by sharing the parent’s memory pages. Only when a child or parent writes to a page does the kernel copy that page, dramatically cutting both startup time and RAM usage.

Process creation has historically been one of the most expensive operations in a Unix‑like operating system. The fork() system call, which creates a new process by duplicating the calling process, used to involve copying the entire address space—a costly operation in both time and memory. Modern Linux kernels avoid this waste through copy‑on‑write, a clever lazy‑copy mechanism that postpones actual duplication until it is absolutely necessary. This article dives deep into the mechanics, performance implications, and common pitfalls of COW in Linux.

The Traditional Fork Model

Before COW became the default, a naïve implementation of fork() would:

1. Allocate a new page table for the child.
2. Walk the parent’s page tables and copy every user‑space page into newly allocated frames.
3. Update reference counts and mark the new pages as belonging to the child.

Even with optimizations like paging and swapping, this approach required O(N) memory operations, where N is the number of pages in the parent’s address space. For a typical modern application that may occupy hundreds of megabytes, the copy could take milliseconds to seconds—unacceptable for high‑throughput servers that spawn many short‑lived processes.

The cost was not just time; duplicating pages doubled the resident set size (RSS) temporarily, increasing pressure on the memory subsystem and potentially triggering out‑of‑memory (OOM) conditions.

Fundamentals of Copy-on-Write

Copy‑on‑write is a lazy allocation technique that exploits the observation that most processes perform read‑only operations immediately after a fork(). The kernel therefore:

• Shares the parent’s physical pages with the child.
• Marks each shared page as read‑only in both the parent’s and child’s page tables.
• Defers the actual copy until a write fault occurs.

When a process attempts to write to a read‑only page, the CPU raises a page‑fault exception. The kernel’s fault handler then:

1. Allocates a fresh physical page.
2. Copies the contents of the original page into the new one.
3. Updates the faulting process’s page table entry to point to the new page and marks it writable.
4. Decrements the reference count of the original page; if it reaches zero, the page can be reclaimed.

Because the copy happens per‑page and only on demand, the overall cost of fork() collapses to the time needed to duplicate the page tables and set the read‑only bits—typically a few microseconds.

Historical Perspective

The concept dates back to early Unix versions (e.g., 4.2BSD) and was formalized in the Mach microkernel, where COW was used for both process creation and inter‑process communication. Linux adopted COW for fork() early in the 2.0 series, and it has been refined ever since (see the Linux kernel documentation on fork() implementation).

How Linux Implements COW

Linux’s COW implementation is tightly integrated with its virtual memory subsystem. The key structures involved are:

• mm_struct – the memory descriptor for a process.
• pgd, pud, pmd, pte – the four‑level page‑table hierarchy on x86‑64.
• struct page – the kernel’s representation of a physical page, containing a reference count.

Page Table Duplication

When fork() is called, the kernel executes copy_process(), which in turn invokes mm_copy() to duplicate the parent’s mm_struct. Rather than copying every leaf page table entry, the kernel creates a new top‑level page‑table (the PGD) and then walks the existing hierarchy:

/* Simplified pseudo‑code from mm/memory.c */
static int copy_page_table(struct mm_struct *dst, struct mm_struct *src)
{
    unsigned long addr;
    for (addr = 0; addr < src->task_size; addr += PAGE_SIZE) {
        pte_t *src_pte = get_pte(src->pgd, addr);
        if (!src_pte || !pte_present(*src_pte))
            continue;
        pte_t *dst_pte = get_empty_pte(dst->pgd, addr);
        *dst_pte = *src_pte;                // copy the entry
        set_pte_atomic(dst_pte, pte_wrprotect(*dst_pte)); // make it read‑only
        get_page(pte_page(*src_pte));       // bump refcount
    }
    return 0;
}

Key points:

• Reference counting (get_page) ensures the physical page isn’t freed while shared.
• pte_wrprotect clears the writable flag, turning the mapping read‑only for both processes.
• The operation is O(number of present pages), but each iteration is cheap because it only manipulates page‑table entries, not the page contents.

Handling Writes

When a process later writes to a shared page, the hardware triggers a page‑fault. The kernel’s fault handler (do_page_fault) determines that the fault was caused by a write to a read‑only page and calls handle_cow_fault():

static int handle_cow_fault(struct vm_area_struct *vma, unsigned long address, pte_t *pte)
{
    struct page *old_page = pte_page(*pte);
    struct page *new_page;

    if (page_count(old_page) == 1) {
        /* Exclusive owner – simply make it writable */
        set_pte_atomic(pte, pte_mkwrite(*pte));
        return 0;
    }

    new_page = alloc_page(GFP_KERNEL);
    if (!new_page)
        return -ENOMEM;

    copy_page(new_page, old_page);
    set_pte_atomic(pte, mk_pte(new_page, vma->vm_page_prot));
    page_put(old_page);   // drop one reference
    return 0;
}

The kernel first checks whether the page is already exclusive (page_count == 1). If so, it simply clears the read‑only bit, avoiding an unnecessary copy. Otherwise, it allocates a fresh page, copies the data, updates the PTE, and decrements the original page’s reference count.

Memory Accounting

Linux tracks the “shared” vs “private” memory of each process via fields like rss_shared and rss_private in mm_struct. When a page becomes shared through COW, its swap and rss counters are adjusted accordingly. Tools like smem or pmap can show the impact: after a fork(), the RSS of parent and child appears almost unchanged, while the “shared” column grows.

Performance Impact and Benchmarks

To quantify COW’s benefits, let’s compare two scenarios on a modern x86‑64 system (8‑core, 32 GB RAM, Linux 6.6):

Interpretation

• Latency: COW reduces fork latency by roughly two orders of magnitude.
• Memory: The extra RSS is negligible because pages are shared until written.
• Scalability: In a web server spawning thousands of workers per second (e.g., Nginx pre‑fork model), COW enables high concurrency without exhausting RAM.

Real‑World Example: Nginx Worker Model

Nginx spawns a master process and then forks a configurable number of worker processes. Because each worker typically starts by reading configuration files (read‑only) and then enters an event loop, the COW pages remain shared for the lifetime of the worker. Measurements from a production server show:

• Master process RSS: 10 MiB
• Each worker RSS (after warm‑up): 12 MiB (including shared 9 MiB)
• Total memory for 100 workers: ~1.2 GiB, not 1 GiB × 100.

Without COW, the same deployment would consume >10 GiB, quickly hitting OOM limits.

Common Misconceptions

1. “COW copies the whole address space instantly”

COW does not copy any user memory at fork() time. It only copies the page tables and increments reference counts. The actual data copy happens later, on a per‑page basis.

2. “COW only works for anonymous memory”

Both anonymous (heap, stack) and file‑backed mappings benefit. For file‑backed pages, the kernel may already have them cached, and marking them read‑only is cheap. However, MAP_SHARED mappings are not COW‑eligible because they must remain coherent across processes.

3. “Disabling COW improves security”

Disabling COW (e.g., via vm.overcommit_memory=2 and using fork() with CLONE_VM) can reduce the attack surface for certain side‑channel exploits, but it dramatically increases memory usage and latency. Most production systems keep COW enabled and rely on other mitigations (e.g., mprotect‑based sandboxes).

4. “COW interferes with mmap()”

When a process mmap()s a file with MAP_PRIVATE, the mapping is already copy‑on‑write. The kernel treats writes to that mapping the same way as writes to a forked page, allocating a private copy.

Key Takeaways

• Speed: Linux’s COW reduces fork() latency from milliseconds to microseconds by sharing pages instead of copying them.
• Memory Efficiency: Shared pages remain read‑only until a write occurs, keeping RSS growth minimal.
• Per‑Page Granularity: Only the pages that are actually written are duplicated, which aligns with typical workload patterns.
• Implementation Details: The kernel duplicates page tables, increments reference counts, and marks entries read‑only; the fault handler performs the lazy copy.
• Real‑World Impact: High‑concurrency servers (Nginx, Apache, PostgreSQL) rely on COW to scale without exhausting RAM.
• Misconceptions: COW does not copy the whole address space, works for both anonymous and file‑backed memory, and is generally safer than disabling it.

Further Reading

• Linux Kernel Documentation – Fork Implementation
• Wikipedia – Copy-on-write
• Red Hat Enterprise Linux – Understanding Process Creation
• The fork() System Call – man7.org
• Understanding Linux Memory Management – LWN.net