Understanding mmap: Concepts, Usage, and Typical Applications in Linux

The author encountered a confusing issue with mmap at work, studied the topic, and now shares the findings, inviting feedback on any mistakes.

Background Knowledge

To use mmap, one must first understand the concept of a process's virtual address space. Linux isolates each process in its own virtual address space while sharing physical memory, so the addresses we manipulate in code are virtual addresses.

When a program requests memory, it actually reserves a region of virtual addresses; physical memory is allocated only when that region is accessed.

On x86 Linux, memory management follows a segment‑page model: the CPU logical address is first converted to a linear (virtual) address, then paged to a physical address. The first access may trigger a page‑fault to allocate the physical page.

Reading a file via the read system call first loads data into the kernel's page cache, then copies it to the user‑level buffer. The kernel maintains an inode for each opened file, which contains an struct address_space *i_mapping that tracks cached pages using an xarray (a radix‑tree implementation).

mmap Overview

Prototype: void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset)

Functions:

Allocate a new contiguous virtual address region (represented by vm_area_struct ) and return its start address; if addr is provided, the allocation prefers that address.

If a file descriptor fd is supplied, map the file's contents into the process's virtual address space.

The prot and flags arguments have many options; consult the man pages for details.

Typical mmap Applications

Shared mapping between different processes (not necessarily parent‑child)

Both processes map the same disk file, so their virtual pages refer to the same physical memory after paging.

Typical usage: open a file and call mmap with the MAP_SHARED flag.

int fd = open("[filepath]", O_RDWR);
void *addr = mmap(NULL, [mmaping length], PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

Communication between non‑child processes

Parent creates a child with fork ; parent and child can share memory via mmap.

Typical usage: no file descriptor needed, use MAP_SHARED | MAP_ANONYMOUS flags.

void *addr = mmap(NULL, BUF_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);

Using mmap in glibc's malloc

When a malloc request exceeds 128 KB, glibc allocates memory via mmap (smaller allocations use brk ).

Typical usage: MAP_PRIVATE | MAP_ANONYMOUS without a file descriptor.

void *addr = mmap(NULL, buffer_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

Write‑time copy‑on‑write

If a file is mapped with MAP_PRIVATE , writes modify a private copy of the page rather than the underlying file, effectively creating an anonymous mapping.

Special notes when mapping disk files

The length argument must be aligned to the physical page size (typically 4 KB on 32‑bit systems). For example, mapping a 5000‑byte file results in an 8192‑byte mapping, with the extra bytes zero‑filled.

Mapping a zero‑length file allocates no physical memory; after writing data to the file, the mapping becomes usable.

mmap and memory swapping

Both file‑backed and anonymous mappings allocate physical pages that may be swapped out under memory pressure; MAP_LOCKED can prevent swapping, but it is not discussed here.

For file‑backed mappings, if the page is evicted, the page‑table entry is cleared and the page will be re‑read from the page cache on next access.

Anonymous mappings without an associated file are swapped to swap space, which resides on disk.