mincore(2)

👑 mincore(2) — the page residency vibe check 👑

okay bestie, so mincore is a Linux system call (manual section 2, system calls, iykyk) and it literally just tells you which of your pages are chillin' in RAM right now. no cap.

---

🌸 NAME 🌸

mincore — determine whether pages are resident in memory

like, is this page in memory or not? that's the whole question. it's giving "where are my pages" energy. 💅

---

🎀 LIBRARY 🎀

Standard C library (libc, -lc)

---

✨ SYNOPSIS ✨

#include <sys/mman.h>

int mincore(size_t length;
            void addr[length], size_t length, unsigned char *vec);

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

mincore():
    Since glibc 2.19:
        _DEFAULT_SOURCE
    glibc 2.19 and earlier:
        _BSD_SOURCE || _SVID_SOURCE

yes bestie, that is literally how it's written. we do not fix the synopsis, we respect the synopsis. 🙈

---

💖 DESCRIPTION 💖

so mincore() hands you back a whole vector telling you whether pages of your calling process's virtual memory are resident in core (that's RAM bestie) — meaning if you touched them, they would not cause a disk access (a page fault) 🫶. the kernel gives you the residency tea about the pages starting at the address addr, and it keeps going for length bytes.

the addr argument must be a multiple of the system page size. no exceptions, the kernel is not flexible on this one. the length argument doesn't have to be a multiple of the page size, BUT — and this is the part people trip on — since residency info comes back for whole pages, length effectively gets rounded up to the next multiple of the page size. you can grab the page size (PAGE_SIZE) with sysconf(_SC_PAGESIZE). slay.

the vec argument must point to an array containing at least (length+PAGE_SIZE-1) / PAGE_SIZE bytes. on return, the least significant bit of each byte gets set if the corresponding page is currently resident in memory, and it's clear otherwise. (the settings of the other bits in each byte are undefined — those bits are reserved for possible later use, so don't you dare read meaning into them 🙈).

and of course the information returned in vec is only a snapshot: pages that are not locked in memory can come and go at any moment, and the contents of vec may already be stale by the time this call returns. it's giving "you blinked and the data changed" 😭. that's not a bug, that's just memory being memory.

---

🔥 RETURN VALUE 🔥

• On success, mincore() returns zero. ✨
• On error, -1 is returned, and errno is set to indicate the error. classic.

---

💀 ERRORS 💀

• EAGAIN — kernel is temporarily out of resources. it's not you, it's the kernel, it's going through something.
• EFAULT — vec points to an invalid address. bestie that pointer is not pointing anywhere real 💀
• EINVAL — addr is not a multiple of the page size. you knew this rule. you were told about this rule. 👀
• ENOMEM — length is greater than (TASK_SIZE - addr). (this could occur if a negative value is specified for length, since that value will be interpreted as a large unsigned integer 🫠). in Linux 2.6.11 and earlier, the error EINVAL was returned for this condition.
• ENOMEM — addr to addr + length contained unmapped memory. yeah, there's a hole in there.

not two ENOMEM entries being a thing but here we are, both are real, both count. ✨

---

🌈 STANDARDS 🌈

None. literally none. she's not standardized, she's just there, doing her thing, living her best life. 💅

---

🦋 HISTORY 🦋

SunOS 4.1, 4.4BSD, FreeBSD 2.2, Solaris 8, Linux 2.3.99pre1, glibc 2.2, NetBSD 1.5, OpenBSD 2.9, AIX 5.1.

she's been around the block, an absolute icon, a legend, a very well-traveled syscall. 👑

---

🍓 BUGS 🍓

before Linux 2.6.21, mincore() did not return correct information for MAP_PRIVATE mappings, or for nonlinear mappings (established using remap_file_pages(2)). so if you're time-traveling back to pre-2.6.21 Linux... good luck bestie, the data was lying to you 😭. (not an issue anymore, but we keep receipts.)

---

💜 SEE ALSO 💜

• fincore(1)
• madvise(2)
• mlock(2)
• mmap(2)
• posix_fadvise(2)
• posix_madvise(3)

---

and that's the whole page, bestie, no cap, we kept every single detail — fr fr. this was brought to you by Linux man-pages 6.20, dated 2026-02-16, and yes, mincore(2) is eating and leaving no crumbs. mwah 💅✨🫶🎀