Virtual Memory and Paging
Virtual memory gives a process an address space that the operating system maps to physical storage and protection rules. Paging divides that space into units that can be mapped, loaded, shared, protected or reclaimed. Address-space size and resident physical memory are different quantities.
Diagnose pressure by following the actual memory category and fault/reclaim behavior. A page fault is not automatically a disk read, and high virtual size alone does not establish that the process has exhausted RAM.
TL;DR
- Separate virtual address space, committed/backed memory and resident pages.
- Trace page number and offset through valid mappings and permissions.
- Distinguish demand faults, protection faults and storage-backed work.
- Measure working set, reclaim and service latency under comparable workload.
- Treat OOM behavior as operating-system and limit-specific.
Quick Example
This complete Python model translates one fictional address and simulates an LRU cache with two frames. It is not a hardware TLB, OS pager or memory benchmark. The chosen page size and replacement policy are declared inputs.
The four misses belong to this idealized reference sequence and policy. They do not predict real page faults, storage I/O or application latency, and the missing-table exception does not reproduce a platform’s fault handler.
Core Concepts
Address translation
On an MMU-equipped system, page tables and cached translations map virtual pages to physical frames with permissions. The offset selects a location within the page. Operating systems can support multiple page sizes and architecture-specific layouts; 4096 is a fixture input, not a universal constant. Linux memory concepts
Address space and residency
A process’s virtual address space is a range of possible addresses with operating-system-defined states and mappings. Reservation, commitment/backing and residency answer different questions. Windows documentation describes its process address-space model; use the actual platform’s counters and limits. Windows address space
Fault and reclaim
A fault may establish a demand mapping, load data, handle copy-on-write or reject prohibited access. Reclaim attempts to free suitable physical memory; some pages can be discarded/recreated, while other work requires writing or reading backing storage. Do not count every fault as equivalent I/O. Windows specifically defines its Working Set counter as currently resident pageable pages and distinguishes hard faults needing backing-store reads from soft faults resolved without them. Keep that platform counter separate from an abstract recent-access locality window. Windows working set
Trace pressure through a workload
Record process and system limits, allocation categories, resident usage, working-set behavior, page faults, reclaim/storage activity and application latency. Align clocks and workload phases before interpreting correlations.
The working set depends on which pages the workload actively needs over an interval. A small input can cycle through more pages than available frames, while a much larger dataset can behave well with locality. Evaluate the actual access pattern rather than assuming dataset size alone determines pressure.
Use a controlled workload change to test a hypothesis: reduce concurrency, bound a cache, improve locality or change a mapping strategy where appropriate. Preserve correctness and useful completion rate. A lower resident number achieved by failing requests is not an improvement.
Understand OOM and recovery limits
Linux documents OOM handling when reclaim cannot provide sufficient memory, including selection of a task to terminate. The observed result also depends on configured system/container limits and allocation context. Do not assume the largest visible heap is always the process terminated. Linux OOM overview
Check logs and limit events before tuning. Memory allocation can fail, a process can be killed, or a service can become unusably slow while paging. Those outcomes need different recovery and admission decisions. Preserve evidence without dumping sensitive process memory casually.
Define a service response to memory pressure: bounded work, rejection/cancellation, restart policy and restoration of necessary state. Increasing a limit can postpone an incident while leaving the original growth or locality problem unchanged.
The Python simulation deliberately omits real page tables, TLB behavior, permissions, dirty pages, file cache, swap, huge pages, NUMA and OOM. Use it to understand the distinction between address mapping and finite residency, then collect actual platform evidence.
Best Practices
Name counters precisely
Record what each platform tool measures and at what scope. Avoid adding overlapping fields or comparing unlike categories as if they were one memory total.
Compare equivalent phases
Separate startup, steady load, idle and recovery. Cold-page activity should not be mistaken for an indefinitely growing leak.
Keep resource tests bounded
Use authorized disposable workloads and explicit limits. A teaching model does not require exhausting the user’s machine or inducing an OOM event.
Common Mistakes
Bad: Equating virtual size with resident RAM.
Correct: Inspect mapping, commitment/backing and residency separately.
Bad: Calling every page fault a disk access.
Correct: Identify the fault type and correlate with actual backing-storage work.
Bad: Increasing memory limits without understanding growth.
Correct: Measure ownership, working set, concurrency and pressure before changing the budget.
FAQ
Is the simulated LRU policy the real OS policy?
No. It is an explicit small model; real replacement and reclaim are more complex and platform-specific.
Does every fault indicate a bug?
No. Some faults are normal demand-management events; prohibited access is a different case.
Were real paging or OOM events measured here?
No. Only address arithmetic, missing-mapping rejection and the declared cache simulation were executed.
Related Topics
- Operating System Concepts — Understand process and kernel boundaries.
- Computer Architecture — Connect translation and hardware.
- Memory Leak and Heap Growth Diagnosis — Separate retention from process-memory behavior.