a memory-mapped file
Imagine that instead of asking a clerk to read you a document line by line over a counter, the clerk simply lays the whole document open on your own desk and says 'it's yours, read or edit any part directly.' You no longer make a request for each line; you just look at the page in front of you, and any change you make on the desk is reflected back into the official file later. A memory-mapped file does this for a program: it places a file directly into the program's address space so that reading or writing the file becomes ordinary reading or writing of memory.
Concretely, a system call such as mmap maps a file (or part of it) into a range of the process's virtual address space. After that, the file's bytes appear as memory: address X in the mapped region corresponds to a particular offset in the file. The program reads and writes that memory normally, with no explicit read or write system calls per access. Behind the scenes it is pure demand paging: when the program first touches a page of the mapped region, a page fault brings that part of the file in from disk into a frame; when a written (dirty) page is evicted or the mapping is flushed, the OS writes it back to the file. Because the page cache backs both, mapped file pages and the kernel's file cache are the same pages, so there is no extra copying between a separate I/O buffer and the program.
Why it matters: memory mapping makes file I/O fast and convenient — you manipulate file contents with plain pointer or array operations, and the OS handles the loading and saving lazily and efficiently. It also enables a clean form of shared-memory inter-process communication: if two processes map the same file with a shared mapping, they see each other's writes through their own memory, since both map onto the same underlying page-cache pages. The honest caveats: errors can surface as faults (a signal) rather than as a return value from read or write, which is harder to handle; mapping a file does not guarantee data is on disk until it is flushed; and mapping is awkward for files whose size changes a lot.
A program maps a 2 GB log file and reads byte 1,500,000,000 simply as mapped[1500000000]. Only the one 4 KB page containing that byte is faulted in from disk; the other ~2 GB stays on disk untouched until referenced.
File access becomes memory access, paged in lazily one page at a time.
A shared mapping of the same file is a real IPC channel — two processes literally share the underlying pages. But a private (copy-on-write) mapping is not: each process's writes stay private and are not seen by the other, and may not be written back to the file at all.