A process with 200MB of memory calls fork(), and the child immediately calls exec(). With copy-on-write enabled, approximately how much memory is actually copied during this sequence?
A200MB — all of the parent's address space must be duplicated at fork() time
B100MB — only writable pages are copied; code pages are shared
CA few kilobytes — only the page tables are duplicated; data pages are never written before exec() replaces them
DNothing — exec() makes any memory copying completely unnecessary
With CoW, fork() copies only the page tables (a few kilobytes), not the data they point to. All physical pages are shared and marked read-only. The child then calls exec(), which replaces the entire address space before any write occurs — so no page faults are triggered and no data pages are ever copied. Option D is close but wrong: the page tables themselves do get copied. Option A describes behavior without CoW.
Question 2 Multiple Choice
After fork() with copy-on-write, a page is marked read-only in both the parent and child page tables. The parent then writes to that page. What happens next?
AThe write is silently ignored to preserve the shared copy
BA segmentation fault is raised because the page is read-only
CThe OS copies the page for the parent, updates the parent's page table to point to the new copy with write permission, and the child keeps the original
DThe OS copies the page for the child, and both parent and child receive new independent copies
The write triggers a page fault — but the OS recognizes it as a CoW fault, not a genuine protection violation. It allocates a new physical frame, copies the shared page's contents into it, updates the *writing* process's page table entry to point to the new copy with write permission, and resumes execution. The other process keeps the original page unchanged. Only the one page is copied, not the entire address space.
Question 3 True / False
With copy-on-write, parent and child processes share physical memory pages until one of them reads those pages.
TTrue
FFalse
Answer: False
Sharing continues through reads — reads are permitted on the shared read-only pages and generate no page fault. Sharing ends only when one process *writes* to a shared page, triggering the CoW page fault and copy. This is critical to why CoW is efficient: most pages in a fork()/exec() pattern are never written at all, so they are shared indefinitely and never copied.
Question 4 True / False
Copy-on-write relies on the page fault mechanism to defer copying until a write actually occurs.
TTrue
FFalse
Answer: True
CoW is implemented by marking shared pages read-only in both page tables. When a write occurs, the CPU cannot complete it — the page-protection hardware raises a fault. The OS fault handler intercepts this, recognizes the CoW flag on the page table entry, performs the copy, upgrades permissions, and resumes. Without page faults as the interception mechanism, the OS would have no way to lazily defer the copy.
Question 5 Short Answer
Explain why copy-on-write makes fork() followed immediately by exec() nearly free in terms of memory copying.
Think about your answer, then reveal below.
Model answer: fork() with CoW duplicates only the page tables, not the physical pages. All pages are marked read-only and shared. exec() then replaces the child's entire address space with a new program before the child ever writes to any shared page. Since no write occurs, no CoW page fault fires, and no data pages are ever copied. The cost of the fork()/exec() sequence is proportional to page table size — a few kilobytes — not the process's data size.
The key insight is that CoW defers the cost to the moment it's actually needed. For the fork()/exec() pattern, that moment never arrives. Even when fork() is used without exec(), most pages (code segments, shared libraries, read-only data) are never written by either process, so they remain shared. In practice, only the small number of modified data pages ever incur the copy cost — typically a tiny fraction of total address space.