the translation lookaside buffer (TLB)

Your program does not use real physical memory addresses — it uses virtual addresses, and a hardware unit translates each one into the physical address where the data actually lives, using page tables the operating system maintains. But walking those page tables takes several memory accesses, and doing that on EVERY load and store would be ruinous. The translation lookaside buffer is a small, very fast cache that remembers recent virtual-to-physical translations so the common case skips the walk entirely.

Concretely, memory is divided into pages (commonly 4 KiB). For each page your code touches, there is a mapping from its virtual page number to a physical page frame. The TLB stores a few dozen to a few thousand of these mappings in hardware right next to the core. On a memory access, the CPU looks up the virtual page in the TLB: a hit returns the physical frame in roughly one cycle, and the access proceeds. A miss means the translation is not cached, and the hardware (or OS) must walk the page tables to find it — a slow operation covered separately. Like data caches, the TLB is usually split (an instruction TLB and a data TLB) and has multiple levels (L1 TLB, L2 TLB).

Why a programmer should care: the TLB caches translations, not data, and it covers only a limited amount of memory — its reach is (number of entries) times (page size). With 64 entries and 4 KiB pages, a single L1 TLB covers just 256 KiB of address space at once. A program that scans across many pages with poor locality can hit the data fine in cache yet still stall on TLB misses, because it touches more distinct pages than the TLB can hold. This TLB pressure is a real and often-overlooked cost, and the main software lever against it is larger pages.