Questions: Demand Paging and Page Faults

Question 1

A process accesses a valid virtual address, but that page is not currently in physical memory. Which sequence correctly describes what happens next?

• A. The process immediately crashes with a segmentation fault because the address is not in RAM
• B. The hardware raises a page fault exception; the kernel allocates a physical frame, loads the page from disk, updates the page table, and restarts the faulting instruction
• C. The OS terminates the process for attempting to access unmapped memory
• D. The hardware automatically fetches the page from disk and continues execution without kernel involvement

Answer: (B)

A page fault on a valid virtual address (one that exists in the process's address space but isn't loaded) is a normal, handled event — not a crash. The hardware detects the missing page-table entry and traps to the kernel's page fault handler. The kernel does the work (allocate frame, load page, update table), then returns to user mode and restarts the instruction. The process never 'sees' the fault. A segfault occurs only when the address is genuinely invalid (not mapped to anything in the process's virtual address space).

Question 2

A system is experiencing thrashing. Which explanation best describes the underlying cause?

• A. The CPU is too slow to service page faults efficiently, causing a fault backlog
• B. The combined working sets of the running processes exceed physical memory, so pages evicted to make room for faults are immediately needed again, causing near-continuous faulting
• C. The page replacement algorithm is poorly tuned and consistently evicts recently-used pages
• D. Disk fragmentation has increased page fault service time, creating a performance bottleneck

Answer: (B)

Thrashing is a systemic resource exhaustion problem, not an algorithmic one. When total demand for physical frames exceeds supply, the OS pages something out to satisfy a fault, but the evicted page is needed almost immediately — triggering another fault. The system spirals: it spends more time on page fault handling than on useful work. The fix is structural: reduce the number of active processes, add RAM, or improve application locality. Replacing the replacement algorithm addresses the wrong level.

Question 3

A page fault does not necessarily indicate a program error — it is the normal mechanism by which valid pages are loaded into memory on their first access under demand paging.

• T. True
• F. False

Answer: True

Demand paging deliberately defers loading pages until they are needed. The first access to any page that hasn't been loaded yet will fault, and this is expected and correct behavior. Operating systems routinely handle millions of such 'minor' or 'cold-start' page faults during normal operation. Only a page fault on an address outside the process's valid virtual memory region (an invalid access) results in an error signal to the process.

Question 4

Demand paging requires that each process's entire virtual address space fit within physical memory, since any page not currently present in RAM will cause the process to crash.

• T. True
• F. False

Answer: False

The entire purpose of demand paging is to allow programs larger than physical RAM. The OS maintains pages on disk (in a swap partition or the executable file itself) and brings them into physical memory only when needed, evicting others if RAM is full. A process may have a 4 GB virtual address space on a machine with 1 GB of RAM — demand paging makes this work as long as the process's active working set (currently needed pages) fits in memory.

Question 5

Why does even a small page fault rate — say, 1 fault per 1,000 memory accesses — have such a disproportionately large impact on overall performance?

Model answer: Because the latency gap between a normal memory access (~100 ns) and a page fault requiring disk I/O (~100 μs for SSD, ~10 ms for HDD) is 1,000× to 100,000×. With 1 fault per 1,000 accesses, the average access time becomes (999 × 100 ns + 1 × 100,000 ns) / 1000 ≈ 200 ns — roughly double. Even this small fault rate cuts effective memory performance in half.

Performance analysis: effective access time = (1 − p) × t_mem + p × t_fault, where p is the fault rate. With p = 0.001, t_mem = 100 ns, and t_fault = 100,000 ns (SSD): EAT = 0.999 × 100 + 0.001 × 100,000 = 99.9 + 100 ≈ 200 ns. The fault term (100 ns contribution) equals the entire no-fault memory time. This is why thrashing — where fault rates spike to near 1 — causes throughput to collapse almost entirely.