Skip to content

CONCEPT Cited by 1 source

Transparent Huge Pages (THP)

Definition

Transparent Huge Pages (THP) is a Linux kernel feature (since 2.6.38, merged in 2011) that transparently promotes contiguous 4 KiB pages to 2 MiB pages (x86-64) without requiring the application to use hugetlbfs or MAP_HUGETLB. The kernel's khugepaged thread periodically scans process address spaces and promotes eligible ranges; applications can hint which ranges are worth the effort via madvise(..., MADV_HUGEPAGE).

THP is the zero-config path to huge pages: the application keeps using normal malloc / mmap(MAP_ANONYMOUS) / etc., and the kernel takes care of promotion when the conditions are right.

Modes

THP has three system-wide modes (controlled via /sys/kernel/mm/transparent_hugepage/enabled):

  • always — kernel attempts to use THP for every allocation. Simplest; worst pathological cases.
  • madvise — kernel only uses THP in ranges that have been MADV_HUGEPAGE-hinted. Most deployments' default. Puts allocator + application in control of where THP is applied.
  • never — THP disabled; explicit hugetlbfs required.

The madvise mode is where userspace allocators like jemalloc's HPA have leverage: they know which virtual ranges are long-lived application heaps (good THP candidates) vs short-lived bookkeeping (bad THP candidates, wasted promotion work).

Why THP is attractive at hyperscale

  • Zero application change — no hugetlbfs mount, no root setup, no application-code change required. Drop-in.
  • TLB-miss reduction — a 2 MiB THP covers 512× the memory of a 4 KiB page in a single TLB entry, reducing page-walk cost for long-lived large-working-set processes.
  • Portable across kernel versions — every modern Linux server has it. No special kernel config required.

Why THP is hard to use well

  • Promotion costkhugepaged promotion is not free; on poorly-laid-out heaps the scanner spends CPU without producing promotable ranges.
  • Demotion under pressure — kernel memory-reclaim can split 2 MiB pages back to 4 KiB, losing the TLB win at the worst moment.
  • Latency spikes — huge-page allocation during a page fault can stall the faulting thread while the kernel compacts memory.
  • Internal fragmentation amplification — a 2 MiB page serving small allocations wastes memory at 512× the grain of a 4 KiB page.

These realities are why an allocator's HPA subsystem has to actively cooperate with THP rather than just letting the kernel figure it out — which is exactly the axis Meta's 2026 jemalloc roadmap names as a focus area.

Seen in

Last updated · 319 distilled / 1,201 read