alloc_hugepages(2)

💖 alloc_hugepages — bestie edition 💖

okay so this is a Linux manual page, and the two stars of the show are alloc_hugepages and free_hugepages — they allocate or free huge pages. that's it, that's the name section, we're keeping it cute and keeping it accurate. ✨

---

🌸 SYNOPSIS 🌸

void *syscall(size_t size;
              SYS_alloc_hugepages, int key,
              void addr[size], size_t size,
              int prot, int flag);
int syscall(SYS_free_hugepages, void *addr);

🚨 REAL TALK: glibc provides no wrappers for these system calls, bestie. none. zero. so you have to go through syscall(2). that's not optional, that's the vibe. 💅

---

🦋 DESCRIPTION 🦋

not me about to tell you the most tragic lore ever: alloc_hugepages() and free_hugepages() were introduced in Linux 2.5.36 and then removed again in Linux 2.5.54. they literally existed only on i386 and ia64 (and only when built with CONFIG_HUGETLB_PAGE). and if you're on Linux 2.4.20? the syscall numbers exist, but the calls just fail with the error ENOSYS. it's giving ghosted. 😭

so on i386, the memory management hardware knows about ordinary pages (4 KiB) and huge pages (2 or 4 MiB). same energy on ia64, except it knows about huge pages of several sizes. these system calls are here to map huge pages into the process's memory, or free them again. and the whole point? huge pages are locked into memory, and are not swapped. periodt.

the key argument is an identifier. here's the tea:

• when it's zero, the pages are private, and not inherited by children.
• when it's positive, the pages are shared with other applications using the same key, and inherited by child processes.

the addr argument of free_hugepages() tells which page is being freed: it was the return value of a call to alloc_hugepages(). (quick note bestie — the memory is first actually freed when all users have released it.) and the addr argument of alloc_hugepages()? that one's just a hint, and the kernel may or may not follow it. 🙈

⭐ WARNING: addresses must be properly aligned. do not skip this.

the size argument is the size of the required segment. it must be a multiple of the huge page size. no exceptions, she's strict. 👑

the prot argument specifies the memory protection of the segment. it is one of PROT_READ, PROT_WRITE, PROT_EXEC.

the flag argument is ignored, unless key is positive. in that case, if flag is IPC_CREAT, then a new huge page segment is created when none with the given key existed. if this flag is not set, then ENOENT is returned when no segment with the given key exists. ikyk. 💅

---

🌈 RETURN VALUE 🌈

on success, alloc_hugepages() returns the allocated virtual address, and free_hugepages() returns zero. she ate that. 🎀

on error, -1 is returned, and errno is set to indicate the error. unfortunate but we move.

---

🔥 ERRORS 🔥

• ENOSYS — the system call is not supported on this kernel. literally doesn't exist on your machine, sorry bestie. 💀

---

🍓 FILES 🍓

• /proc/sys/vm/nr_hugepages — number of configured hugetlb pages. this can be read and written. flexible queen.
• /proc/meminfo — gives info on the number of configured hugetlb pages and on their size in the three variables HugePages_Total, HugePages_Free, Hugepagesize. three icons in one file honestly.

---

✨ STANDARDS ✨

Linux on Intel processors. that's the whole section, keep scrolling. 🫶

---

👑 HISTORY 👑

these system calls are gone. they existed only in Linux 2.5.36 through to Linux 2.5.54. a limited run, a cult classic, we mourn her. 🦋

---

💜 NOTES 💜

now the hugetlbfs filesystem can be used instead. memory backed by huge pages (if the CPU supports them) is obtained by using mmap(2) to map files in this virtual filesystem. that's the modern upgrade, no cap.

the maximal number of huge pages can be specified using the hugepages= boot parameter. 🌸

---

and that's the whole page, bestie!! 💖✨🎀 this little legend is from Linux man-pages 6.20, dated 2026-02-08, so you know it's fresh. mwah 💅🫶