memory mapping

Memory mapping is the mechanism by which a file (or an anonymous region) is attached to a process’s virtual address space via mmap(2), so that ordinary loads and stores on addresses in that range translate into reads and writes of the underlying pages. For a file-backed mapping, the pages are served from the kernel page cache; for an anonymous mapping, they come from zeroed pages allocated on first touch.

Memory mapping is the shortest path between a process and its data when the data lives on disk or in shared memory. It sidesteps explicit read/write syscalls for the steady state — only the initial page faults cross into the kernel. Databases, in-memory indexes, mmap-backed columnar stores (DuckDB, Parquet readers), and shared-memory IPC all lean on it.

Key flags:

• MAP_PRIVATE vs MAP_SHARED — whether writes go back to the underlying file (shared) or are CoW’d into private pages (private).
• MAP_ANONYMOUS — no backing file; zeroed pages.
• MAP_POPULATE — pre-fault all pages at mmap time.
• MAP_FIXED — map at an exact address.
• MAP_HUGETLB / MAP_HUGE_2MB / MAP_HUGE_1GB — request huge-page backing.

Performance gotchas: the first touch of every page faults, which is an invisible latency tail unless you pre-populate. TLB coverage is limited, so huge mmap regions benefit from huge pages. On NUMA systems, first-touch allocates on the local node — relevant when an mmap region is shared across threads pinned to different sockets.