What the TLB does during address translation

A process uses virtual addresses, which the memory-management unit translates through page tables into physical memory locations. The CPU keeps recent translations in a translation lookaside buffer (TLB) so it does not have to walk the page tables on every access. If a workload touches a large memory set, smaller pages can require more distinct translations than the TLB can retain. A larger page can let one translation cover a wider address range and may reduce that pressure. The benefit depends on the processor, page sizes, access pattern, and virtualization setup; a page-size ratio is not a prediction of end-to-end speedup.

Concept diagram comparing a reserved HugeTLB pool with THP promotion, showing wider address translations and memory trade-offs

HugeTLB reserves a pool of large pages

Linux kernel documentation describes HugeTLB as pools that can be inspected through /proc/meminfo and sysfs. The counters distinguish total, free, reserved, and surplus pages. An administrator can request persistent pages at boot or adjust pools at runtime, but supported sizes depend on the architecture. The kernel documentation uses 2 MiB and, where supported, 1 GiB as examples; they are not universal values for every processor. Memory reserved for HugeTLB is unavailable for ordinary allocation while reserved, and HugeTLB pages cannot be swapped out under memory pressure. Reserving too much can therefore leave less memory available to other work.

Allocating a pool depends on physically contiguous free memory. Reserving at boot can improve the chance of finding larger contiguous regions before memory becomes fragmented, while runtime allocation depends on the current state of memory. NUMA policy also affects where pages are obtained and how a pool is distributed. A counter showing free HugeTLB pages does not prove that a particular application is using them: the application must request or map the pages through a supported mechanism, such as hugetlbfs, MAP_HUGETLB, or shared-memory interfaces.

THP lets the kernel manage mappings dynamically

Transparent Huge Pages (THP) let the kernel promote or demote mappings without requiring an application to reserve a fixed pool in advance. Current kernel documentation also describes multi-size THP, which can use blocks larger than a base page but smaller than the traditional PMD-sized mapping. The page sizes and memory types supported depend on the architecture and kernel. khugepaged can scan eligible regions and collapse base pages; settings can apply system-wide or be restricted to selected processes or address ranges.

Automatic management does not make the cost disappear. Creating, splitting, or moving large mappings can require memory work, and a large page may use more memory than needed when an application touches only a small part of a wide region. For some large working sets, fewer translations and page faults may help. For other workloads, compaction, memory footprint, or access patterns can offset the benefit. The documentation therefore supports comparing choices in context, not a blanket claim that THP always helps or always harms.

Expert perspective: configuration guidance is not a performance guarantee

Red Hat Enterprise Linux 10 documentation distinguishes reserved HugeTLB pages from THP’s system-wide and per-process modes. It explains that boot-time reservation can improve the chance of obtaining larger contiguous regions before fragmentation, while its examples depend on the target system. The chapter explicitly asks administrators to consider their system requirements and objectives before applying example settings. That product guidance does not establish that every database should disable THP or that static HugeTLB will always be faster.

A useful comparison begins with the actual CPU and kernel, supported page sizes, application mapping behavior, NUMA placement, and memory headroom. If settings are tested, compare the same workload and measurement window before and after, including latency distribution, memory consumption, page faults, and available TLB-related counters. Record the configuration with the result. A finding from one server or application should not be presented as a guarantee for another environment.

Sources