the page cache

Disks are thousands of times slower than RAM, and programs read the same files over and over - the same shared library, the same config, the same hot database pages. It would be madness to fetch them from disk every time. So the kernel keeps recently used file data sitting in RAM and serves repeat reads from there. That in-RAM store of file contents is the page cache, and on a busy machine it quietly becomes the single biggest user of memory.

The page cache holds file data in page-sized chunks (typically 4 KiB) keyed by which file and which offset they came from. The first time anything reads a region of a file, the kernel copies it from disk into a free page and hands the program a copy; the page then stays cached. The next read of that same region - by the same program or any other - is served from RAM with no disk access at all. Writes go the other way: a normal write() updates the cached page in RAM and marks it dirty (changed but not yet on disk), returning to your program immediately; the kernel writes dirty pages back to disk later. A memory-mapped file (mmap) maps these same cached pages straight into your address space, so reading the mapping and reading the file share one copy of the data. Historically Unix had a separate buffer cache for raw disk blocks; modern Linux unified them, so the page cache holds both file pages and block buffers.

Why it matters: the page cache is why the second run of a build, or the second load of a program, is dramatically faster than the first - the data is already in RAM. Free RAM looks alarming on a busy server but is mostly page cache, which the kernel will instantly drop to satisfy real allocations, so cached memory is available, not wasted. The honest catch: because a successful write() only reaches the page cache, your data is in volatile RAM until writeback or an explicit fsync() flushes it to stable storage - the page cache is what makes writes fast and also what makes them not yet durable.