§19.3–19.5Who Handles The TLB Miss? … TLB Issue: Context Switches

The miss path exists — someone has to walk it. Two very different answers, from two eras of computer architecture.

19.3 Who Handles The TLB Miss?

With a hardware-managed TLB hardware-managed tlb On a miss the hardware itself walks the page table (whose location AND format it must know exactly — x86 via CR3), refills the TLB, and retries; the CISC-era design. defined in ch. 19 — open in glossary (the CISC tradition — x86 today), the hardware handles misses entirely: it knows the page table’s location (via CR3) and its exact format, walks it, refills the TLB, retries. With a software-managed TLB software-managed tlb On a miss the hardware just raises an exception; an OS trap handler walks whatever page-table structure it likes, refills the TLB with privileged instructions, and returns to RETRY the faulting instruction (MIPS, SPARC). defined in ch. 19 — open in glossary (the RISC tradition — MIPS, SPARC), the hardware does almost nothing:

VPN = (VirtualAddress & VPN_MASK) >> SHIFT
(Success, TlbEntry) = TLB_Lookup(VPN)
if (Success == True)   // TLB Hit
    if (CanAccess(TlbEntry.ProtectBits) == True)
        Offset   = VirtualAddress & OFFSET_MASK
        PhysAddr = (TlbEntry.PFN << SHIFT) | Offset
        Register = AccessMemory(PhysAddr)
    else
        RaiseException(PROTECTION_FAULT)
else                  // TLB Miss
    RaiseException(TLB_MISS)

One line — and the OS’s trap handler does the rest. Step through all three paths a reference can take:

Two details reward attention. The return-from-trap must resume at the faulting instruction — not after it, as with a syscall — so the hardware saves a different PC depending on what caused the trap. And the handler itself must never trigger an infinite chain of TLB misses: keep the handler in unmapped physical memory, or reserve wired, permanently-valid TLB slots for it. The payoff of the software approach: flexibility (the OS can use any page-table structure it wants) and simplicity (the hardware’s miss path is one line).

19.4 TLB Contents: What’s In There?

A typical TLB has 32, 64, or 128 entries and is fully associative fully associative Any translation can sit in any TLB entry, and the hardware searches all entries in parallel — so each entry must store the VPN alongside the PFN. defined in ch. 19 — open in glossary : any translation can sit in any entry, and the hardware searches them all in parallel. That’s why each entry stores both halves of the mapping:

The “other bits” carry the interesting state: a valid bit (is a translation cached here?), protection bits (r/w/x, checked on the hit path), and often an address-space identifier and dirty bit.

19.5 TLB Issue: Context Switches

TLB contents are only meaningful for the process that created them. Switch from P1 to P2 and the cache becomes a trap:

Fix #1 — flush: on every switch, set all valid bits to 0 (via a privileged instruction, or automatically when the PTBR is written — the OS changes it on a switch anyhow). Correct, simple — and every switch now buys a fresh burst of misses as the new process re-touches its pages. Switch frequently and the cost bites.

Fix #2 — tag the entries: an address space identifier (ASID) address space identifier ASID: a small per-process tag (like an 8-bit PID) in each TLB entry letting translations from different processes coexist — the alternative to flushing the whole TLB on every context switch. defined in ch. 19 — open in glossary per entry — think of it as a compact PID (typically ~8 bits). Translations from different processes coexist; the OS just sets a privileged register to the current ASID at switch time:

And the mirror-image situation is not a bug but a feature:

Sharing code pages (binaries, shared libraries) reduces the number of physical pages in use — the payoff protection bits promised back in the segmentation chapter, alive and well under paging.