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 beenMADV_HUGEPAGE-hinted. Most deployments' default. Puts allocator + application in control of where THP is applied.never— THP disabled; explicithugetlbfsrequired.
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
hugetlbfsmount, 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 cost —
khugepagedpromotion 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¶
- sources/2026-03-02-meta-investing-in-infrastructure-jemalloc-renewed-commitment — Meta's 2026 jemalloc roadmap names improving HPA utilisation of THP as one of four headline focus areas for CPU efficiency.
Related¶
- concepts/huge-page-allocator — the allocator-side subsystem that targets THP.
- systems/jemalloc — whose HPA is the canonical allocator instance.