Demand paging and fault handling

The operating system records which address ranges a process may access and under what conditions. That range-level policy is distinct from the presence of every hardware page-table entry. On a first anonymous write, the kernel may need to allocate a frame, supply zeroed memory, install a writable mapping, and resume the instruction. A first read can sometimes use an existing shared zero page instead. Details depend on architecture, mapping type, page size, and kernel policy; do not assume that reading one byte proves an entire allocation has private physical backing.

The instruction that caused a recoverable fault is retried after the mapping is repaired. A fault on an invalid range or a genuinely forbidden access cannot be repaired merely by finding more free RAM. The kernel instead delivers the appropriate signal or otherwise handles the error. Mapping operations themselves can fail earlier, so robust software checks their return values as well as planning for runtime memory pressure. Lazy allocation changes the time at which resources are needed; it does not remove the resource requirement.

Linux resource counters distinguish minor faults, resolved without the page-loading I/O counted as a major fault, from major faults requiring that I/O. Mapping a file whose contents are already in the page cache can fault without a fresh storage read. Demand-zero allocation and ordinary copy-on-write commonly appear as minor faults. A minor fault still consumes kernel execution and may encounter allocation contention; its name is not a latency guarantee. A major fault is also not proof that a particular application read call issued exactly one disk operation.

Measure differences in counters around the workload phase of interest. A cumulative fault count includes initialization that may be irrelevant to a steady-state regression. Align the count with wall time, system CPU time, memory pressure, and storage activity. Shared page-cache state can make repeated runs faster, while background workloads may change that state again. Document whether the benchmark intends a warm-cache or cold-start comparison and avoid dropping host caches indiscriminately on a machine serving unrelated work. A reproducible experiment controls what it can and records what it cannot.

A service may initialize a bounded pool and deliberately touch pages before accepting traffic. That can make initial mapping and allocation work visible during readiness checks. It does not guarantee future residency: reclaim, copy-on-write, mapping changes, and growth can introduce faults later. Locking memory has separate limits and consequences and is not a universal optimization. Start with the latency requirement and an explicit memory budget; a blanket prefault of every reserved byte can transform a cheap address reservation into an avoidable physical-memory crisis.

In the queue lab, interpret arrivals as normalized fault-service requests and service as simplified capacity. Press Reset, explicitly set arrival two and service three, predict the initial four-job backlog drains after four model seconds, then Play or Step. For a separate comparison, Reset again, set both arrival four and service three, predict one-job-per-second growth from four, then Play or Step. These are separate runs, not a live rate switch: parameter edits retain elapsed time and recompute the initial-value model. The graph does not represent Linux fault queues, page-cache readahead, or thread scheduling. Its separate M/M/1 mean needs Poisson arrivals, exponential service times, one server, and stability; an average cannot guarantee a deadline.