huge / large pages

The default unit of virtual memory is a 4 KiB page, and the TLB can only remember a fixed number of page mappings at once. So if each mapping covers only 4 KiB, the total memory your translations can reach before a TLB miss is small. A huge page solves this from the other direction: instead of mapping more entries, make each entry cover far more memory. A huge page is simply a single page that is much larger than 4 KiB — commonly 2 MiB, and sometimes 1 GiB on x86-64.

The payoff is a multiplier on TLB reach. One TLB entry for a 2 MiB page covers 512 times as much address space as a 4 KiB entry, so a program working over a large region needs far fewer TLB entries to map it, suffers far fewer TLB misses, and triggers far fewer page-walks (the page-table tree is also shallower, since one big leaf replaces a whole subtree of small ones). You get huge pages either explicitly — Linux exposes them via hugetlbfs, the MAP_HUGETLB flag to mmap(), or libraries that allocate from a reserved huge-page pool — or transparently, where the kernel's Transparent Huge Pages feature silently promotes eligible 4 KiB regions to 2 MiB ones in the background.

Be honest about the trade-offs, though. Huge pages must be physically contiguous, so they are harder to allocate, especially once memory is fragmented — a reservation may fail or stall. They are coarse: mapping, protecting, or copying-on-write a 2 MiB page touches all of it at once, which can waste memory or cause latency spikes (transparent huge pages in particular have historically caused unpredictable stalls during background compaction, and some latency-sensitive systems deliberately disable them). Huge pages are a targeted fix for measured TLB pressure on large working sets, not a free global speed-up — apply them where the profiler shows page-walk cost, not everywhere.