= Memory-mapped file
{wiki}
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.<Page Cache by The kernel development community>[Page Cache, opening paragraph: normal reads, writes and mmaps go through the page cache; bypass paths exist]{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.
Back to article page
