Question bank — Virtual memory — concept, page table, virtual-to-physical translation

False. Offset indexes within a page; since a frame is the same size and same alignment as a page, the within-block position is identical, so offset bits pass through untouched — only VPN→PFN is translated.

Usually false, deliberately. Isolation means each process has its own page table, so identical VAs normally map to different frames. It's only true when the OS intentionally shares a frame (shared library, shared memory, copy-on-write parent/child).

True in practice. It reserves one entry per possible virtual page ($2^{20}$ entries at 4 KiB pages) whether or not the page is used, which is why real systems use Multi-level Page Tables that only allocate sub-tables for touched regions.

False. Fewer entries and fewer TLB misses, yes — but bigger pages waste more to internal fragmentation and force reading more data per page fault. It's a trade-off, which is why OSes offer both 4 KiB and huge pages.

False as stated — two is only the lower bound. A single-level table needs exactly two (one to read the entry, one for the data), but Multi-level Page Tables add one RAM trip per level: a 4-level table needs 4 lookups + 1 data trip = 5. Two is the minimum because you must read at least one table entry then the data itself.

False in general. A fault on a valid but not-resident page is normal — the OS just loads it from disk and retries. It's only an error (segfault) when the address is genuinely unmapped or violates permissions.

True. You need exactly $p$ bits to address every one of the $2^p$ bytes inside a single page ($p$ is just the exponent of the page size); the remaining high bits form the VPN.

False. Over-commitment is a core purpose: unused pages live on disk (swap), so total virtual memory across processes can far exceed physical RAM.

Error: you must scale the frame number by the page size first: $\text{PA}=\text{PFN}\cdot 2^p+\text{offset}$, i.e. concatenate PFN (high bits) with offset (low $p$ bits). Plain addition would collide frame bases with offsets.

Error: it's swapped. The remainder (VA mod 2^p) is how far into the page → offset; the quotient (⌊VA / 2^p⌋) is which page → VPN.

Error: page tables persist in RAM per process; the switch just reloads the page-table base register (CR3 on x86 — it holds the address of the current table) to point at the new process's table. See Context Switching and CR3 / Page-Table Base Register.

Error: the valid bit says whether the mapping/page is present in RAM; cache residency is a separate concern handled by Cache Memory and Locality, not the page table.

Error: it needs $2^{20}$ entries × 4 bytes = $2^{22}$ bytes = 4 MiB, not $2^{20}$ bytes. Confusing entry count with byte count undercounts by the entry size.

Error: page size sets where the VPN/offset boundary falls, so it decides how many bits get translated versus passed through — it fully shapes the split, even though the offset value itself survives.

Because frames and pages are the same size ($2^p$) and both aligned to $2^p$ boundaries, the position inside the block is preserved: $\text{VA}=\text{VPN}\cdot 2^p+\text{off}$ becomes $\text{PA}=\text{PFN}\cdot 2^p+\text{off}$, same off.

Whole-program relocation causes external fragmentation (free RAM exists but no single hole fits). Equal-size pages let any free frame hold any page, so placement is trivial — at the cost of a little internal fragmentation in the last page.

For isolation. A private map lets identical virtual addresses land on different frames, so one process cannot read or corrupt another's memory — the central protection guarantee of paging.

The instruction never completed its memory access (the data wasn't there), so there's no partial state to resume; after the OS fixes the mapping, re-executing it cleanly performs the now-valid access.

The page table lives in RAM, so consulting it costs a memory trip (or several, with multi-level tables) per access. The TLB caches recent VPN→PFN mappings on-chip so most translations skip RAM entirely — locality makes this hit rate high.

They allocate a sub-table only for regions of the address space actually used; unused high-level entries stay empty, so a sparse process pays for a few small tables instead of a full $2^{20}$-entry array.

Spatial locality — nearby bytes are very likely to be accessed soon, so bringing in the whole aligned page amortises the expensive disk trip across many future accesses.

The offset is 0 — the address sits at the very start of a page, so it maps to the base of its frame: $\text{PA}=\text{PFN}\cdot 2^p$.

Translated like any other via PageTable[0]. Many OSes deliberately leave VPN 0 invalid so that dereferencing a NULL pointer faults immediately — a policy choice, not a hardware rule.

It touches two virtual pages, so the MMU performs two translations; the two pages may map to non-adjacent frames, and either translation can independently fault.

A protection/segmentation fault, not a swap-in. The fault handler distinguishes "not resident, fetch from disk" from "no such mapping, kill the process."

$2^{16}/2^{10}=2^6=64$ pages — that's the ceiling on page-table entries because only 64 distinct VPNs can exist in that space.

Yes — that's aliasing (e.g. two virtual addresses of one shared buffer). It's legal; the page table just stores the same PFN in two entries, and the hardware doesn't forbid it.

The OS clears its valid bit (and records the disk location); the next access faults, triggering a swap-in and re-marking it valid — the mechanism behind Page Replacement Algorithms (LRU, FIFO, Clock).

Yes — a process can only name PFNs its page table points to, so surplus frames simply hold other processes' pages or stay free; nothing forces a one-to-one exhaustion.

No — that's the naïve design. Many CPUs tag each TLB entry with an ASID (address space identifier), so entries from different processes coexist and only the matching process's entries are used. This avoids flushing on every switch. See Context Switching and CR3 / Page-Table Base Register and TLB — Translation Lookaside Buffer.