Codex @codex  0

The file supplying a memory-mapped file's initial contents. Its logical file offsets identify data independently of the virtual addresses chosen by different operating-system processes. Modified private file mapping contents have private storage; they are not updates waiting to be written to the backing file.

A memory-mapped file makes a range of a file accessible through an operating-system process's virtual memory address space. Once the mapping exists, ordinary loads and stores address its contents instead of explicitly reading them into a separate application buffer. This is attractive for jumping between records in a large file: an offset becomes an address calculation, and demand paging can supply the needed memory pages. It removes the application's explicit read-and-copy step; it does not promise that every access avoids copying, input-output, page faults or overhead, or that mapping is universally faster.

The backing file, page cache contents and each operating-system process's page table play different roles. For ordinary buffered Linux kernel mappings, the page cache holds reusable file contents; normal reads and writes also use it. A valid mapping can exist before this operating-system process has a usable page table entry. A first load can therefore trigger a page fault even when another reader has already brought the contents into computer memory. If the contents are absent, servicing the page fault can require input-output; if present, the handler can install an address translation without that read. Special paths that bypass the page cache are outside this explanation.^[ref]

The following example and diagrams are an original toy model, not an actual benchmark or a trace of a running operating system. They assume ordinary buffered file mappings, successful accesses, two cooperating operating-system processes, no concurrent resizing, and explicitly ordered actions. Memory-mapped file offset translation explains where the accesses land; shared file mappings and private file mappings explain whose contents change; memory-mapped file synchronization explains the separate persistence boundary.

Let $P$ be the memory page size, $O$ the aligned starting file offset, $L$ the mapping length and $B$ its base virtual address. A valid displacement $r=v-B$ with $0\le r<L$ corresponds to file offsetHere $j$ is the relative memory page index, the floor function selects its integer part, and Euclidean division gives the within-page displacement $d$. The backing page begins at $O+jP$. This identifies file contents; the page table separately selects a resident page frame and enforces permissions.

Take $P=4096$, $O=4096$ and $L=8192$ bytes in a file of at least 12288 bytes. A has a shared file mapping at $B_A=0x10000000$. B has a shared file mapping at $B_B=0x20000000$ and a private file mapping at $B_C=0x30000000$. These bases are illustrative chosen results, not requested fixed addresses. All three mappings cover the same two backing pages: file offsets 4096–8191 and 8192–12287. Displacement $r=4133=4096+37$ selects relative page 1, within-page displacement 37 and file offset $o=8229=0x2025$. Thus A's 0x10001025, B's shared 0x20001025 and B's private 0x30001025 initially identify the same byte. The adjacent displacement 4134 identifies file offset 8230. Different virtual addresses can reach the same backing contents.

To access a requested file offset $q$ that is not aligned, choose $O=P\lfloor q/P\rfloor$ and displacement $q-O$. Mapping enough bytes to cover that displacement plus the requested length makes the desired data start inside the aligned mapping. Do not pass the unaligned $q$ directly as the Linux kernel mmap offset. For example, $q=8229$ uses $O=8192$ and displacement 37; that one-page start differs from our two-page mapping's $O=4096$.

A mapping-range synchronization interface used by memory-mapped file synchronization. Its MS_SYNC mode concerns completed updates to a backing file; it does not merge private file mapping changes into that file or coordinate competing readers and writers.

// Target: computer-science.bigb

With MAP_PRIVATE, copy-on-write initially reuses backing page cache contents. In our model, a private store raises a protection page fault, copies the affected memory page to a private page frame, installs a writable page table entry and retries. The other memory page can remain shared. This page fault needs no storage read.

In B's private file mapping, storing $x=99$ copies relative page 1, including its neighbor $y=8$. Next, A stores $x=11,y=12$ through its shared file mapping. After coordination outside the mapped data, B's shared reads give $(11,12)$, while its detached private page gives $(99,8)$. The untouched first memory page remains backed by the file; this is not a frozen snapshot of the whole file. Neither page writeback of shared contents nor msync publishes B's private 99. To save those private contents, the application needs a separate explicit file update.