Pre-Allocated, Guaranteed, Pinned
Explicit HugePages — also called HugeTLB pages — take the opposite approach from THP. Instead of the kernel automatically promoting pages in the background, an administrator explicitly reserves a pool of HugePages at system startup. Applications then request memory from this pool directly.
The key properties of explicit HugePages:
Pre-allocated: When you set vm.nr_hugepages=1000, the kernel immediately carves out 2GB of RAM (1000 × 2MB) and holds it in reserve. This reservation happens at configuration time, not at application startup.
Pinned (non-swappable): HugeTLB pages are never swapped to disk. For a database, this is critical — you never want your buffer pool suddenly paged out to a spinning disk because the kernel decided to reclaim memory.
Guaranteed: If the pool has 1000 pages and your application requests 500, it gets exactly 500 with no background interference. There is no khugepaged running, no compaction, no latency spikes.
Exclusive: The reserved memory is unavailable to any other process. If Postgres is allocated 32GB of HugePages but is only using 20GB, the remaining 12GB sits idle — it cannot be used by other applications or the OS page cache.
The current allocation is visible in /proc/meminfo as a handful of HugePages_* fields plus the configured Hugepagesize. The pool itself is sized with the vm.nr_hugepages sysctl, which can be set at runtime and made persistent across reboots via /etc/sysctl.conf.
Understanding the /proc/meminfo fields:
| Field | Meaning |
|---|---|
HugePages_Total |
Total pages reserved in the pool |
HugePages_Free |
Pages in the pool not yet mapped by any process |
HugePages_Rsvd |
Pages promised to a process but not yet faulted in |
HugePages_Surp |
"Surplus" pages above the configured limit (rare) |
The distinction between Free and Rsvd matters: a Postgres process might reserve 8192 pages at startup but only fault in (actually use) 6000 of them. Those 2192 pages show as Rsvd — committed but not yet physically accessed.