a TLB miss

Continuing the sticky-note picture: a TLB miss is the moment a visitor asks about a room whose translation is not on the receptionist's sticky note. Now the receptionist must actually open the big directory, look it up, and jot the result onto the note for next time. A TLB miss is when the hardware looks for a translation in the TLB and does not find it, forcing the slower path of reading the page table.

Concretely, on a TLB miss the virtual page number was not cached, so the translation must be fetched from the page table in memory — a process called a page-table walk. On many systems dedicated hardware walks the multilevel page table automatically (touching memory once per level); on others, the miss traps to a software handler in the OS. Either way, the found mapping is then installed into the TLB so the next access to that page hits. Crucially, a TLB miss is NOT the same as a page fault: a TLB miss means the translation simply was not cached (the page may well be present in RAM), whereas a page fault means the page itself is not in memory at all. A TLB miss costs a handful to a few dozen cycles; a major page fault costs millions.

Why it matters: TLB misses are a genuine, often-overlooked performance cost. Code that strides through memory in a scattered, large-footprint pattern — touching many different pages — can miss the TLB constantly even while the data cache behaves fine, because the data fits in cache lines but the translations overflow the TLB's tiny capacity. This is why huge pages, tiling, and TLB-aware data layout matter for high-performance work, and why measuring TLB miss rate (not just cache miss rate) is part of serious performance tuning.