← Interview Prep

Linux Kernel — The Page Cache

Caching file data in RAM: the address_space/xarray index, reads & readahead, buffered writes → dirty pages → writeback (dirty_ratio, flusher threads, fsync durability), unified buffer cache, Direct I/O (O_DIRECT) and mmap, fadvise/drop_caches, and clean-vs-dirty under reclaim.

Why reading the same file twice is nearly free, and why a "used" machine shows little free memory — the page cache keeps file data in RAM. How it's indexed, how reads and writes flow through it, and when you bypass it. Original, interview-focused notes.

The page cache holds file contents in page frames, indexed by (inode/address_space, offset). Reads are served from it (a hit avoids disk); writes land in it as dirty pages and are flushed to disk later. It's why Linux "uses all your RAM" — that memory is reclaimable cache, not waste.

What it is & how it's indexed

• Every open file's data lives in an address_space; its pages are stored in an xarray (radix tree) keyed by file offset, so "is offset N cached?" is a fast lookup.
• The old separate buffer cache (raw disk blocks) is unified with the page cache — buffers are just views into cached pages. In free, buff/cache is this memory.

Reads & readahead

• A read() checks the page cache: hit → copy to userspace, no I/O; miss → allocate a page, read from disk (a major fault for mmap'd files), insert into the cache, then copy.
• Readahead: on sequential access the kernel prefetches the next pages, so later reads hit — the big reason sequential I/O is fast. It backs off on random access.

Writes, dirty pages & writeback

• A buffered write() copies into cache pages and marks them dirty — it returns before the data is on disk. Fast, but the data is only in RAM.
• Writeback flushes dirty pages later: kernel flusher threads write them out when dirty memory crosses thresholds (vm.dirty_ratio / dirty_background_ratio) or after dirty_expire time. Dirty/Writeback in /proc/meminfo track this.
• Durability is explicit: fsync()/fdatasync() force a file's dirty pages (and metadata) to stable storage. Skipping it is the classic "data lost on power cut" bug — the write "succeeded" but only into cache.

Bypassing & managing it

• Direct I/O (O_DIRECT) skips the page cache — the app manages its own caching (databases that don't want double-buffering).
• mmap maps page-cache pages straight into the process, so file access is memory access (shared across processes mapping the same file).
• posix_fadvise / madvise hint access patterns (WILLNEED, DONTNEED, SEQUENTIAL); echo 1 > /proc/sys/vm/drop_caches drops clean cache (diagnostics only — never a real fix).

Under memory pressure, clean cache pages are the first thing reclaimed (no writeback needed); dirty pages must be written first. See Page Frame Reclaiming.