Linux does not like leaving useful RAM idle. When programs read ordinary files, the kernel can keep recently used file data in memory so the next read may be served from RAM instead of going back to slower storage. That memory-backed layer is called the page cache.
The simplest way to think about it is: storage holds the durable copy, while the page cache keeps useful file-backed data close to the CPU. This is why a large file can take noticeable time to read once and then appear dramatically faster on a second read.
The Page Cache Sits Between Programs And Storage
For normal buffered file I/O, Linux commonly moves file contents through the page cache. The official Linux kernel page-cache documentation describes the page cache as the primary way users and the kernel interact with filesystems for ordinary reads, writes, and memory mappings.
A program can open a file through a file descriptor and request data with a system call. If the needed file data is already cached in RAM, the kernel can often satisfy that request without waiting for another storage read.
Why The Second Read Can Be Much Faster
Imagine a program reads a 2 GB file from an SSD. During the first read, the kernel must fetch blocks from storage and place the corresponding file data into memory. If enough of those pages remain cached, a second read of the same file can reuse them directly from RAM.
RAM latency and bandwidth are very different from SSD or hard-drive access, so a cache hit can remove much of the storage wait from a repeated workload. The speedup is not magic and it is not guaranteed: the data must still be present in memory, and the workload must actually reuse it.
Reads Bring File Data Into RAM
When a normal read misses the page cache, Linux has to obtain the requested file data from the backing filesystem and storage device. Once that data arrives, the kernel can retain it in RAM so nearby or repeated accesses may reuse it.
This behavior also connects to virtual memory. File-backed memory and anonymous process memory both live in physical RAM, but Linux can treat them differently when memory pressure rises because clean file-backed cache can often be discarded and re-read from storage later.
Writes Can Become Dirty Pages
The page cache is not only for reads. Normal buffered writes can first modify file-backed memory in RAM. Once the cached copy differs from the durable copy on storage, Linux marks that memory as dirty.
Dirty pages cannot simply be discarded, because they contain changes that storage does not yet have. The kernel eventually performs writeback, sending those modifications to the backing device. The Linux Virtual File System documentation describes how file-backed address spaces track dirty and writeback state.
The Page Cache Is Not The Same As A CPU Cache
The word “cache” appears in several parts of a computer, but the layers are different. CPU cache such as L1, L2, and L3 keeps frequently needed memory close to processor cores. The Linux page cache is managed by the operating system and keeps file-backed data in system RAM.
- CPU cache: tiny and extremely fast hardware-managed memory near the processor.
- Page cache: operating-system-managed RAM containing file-backed data.
- Storage device cache: memory inside or near a storage controller or device.
- Application cache: data a program intentionally keeps for reuse.
Why Linux Can Show Very Little Free RAM
Linux often uses otherwise-idle memory for cache because unused RAM does not make the machine faster. This can make a system appear to have very little completely free memory even when it still has plenty of memory that can be reclaimed for applications.
free -hOn modern Linux systems, the available figure is usually more useful than staring only at free. Cached file data can often be discarded when programs need RAM, provided those cached pages are clean or their dirty contents have first been written back.
Memory Pressure Can Reclaim Clean Cache
Linux continuously balances RAM among process memory, kernel needs, file-backed cache, and other uses. When applications demand more memory, clean cached file pages are attractive reclamation targets because the durable data already exists on storage.
If Linux later needs that file data again, it can read it back from the filesystem. This tradeoff is central to cache design: keep data nearby while RAM is available, then give that RAM back when something more important needs it.
Memory-Mapped Files Also Use The Page Cache
A program does not always have to call read() repeatedly to access file data. With mmap(), the kernel can map file-backed pages into a process’s virtual address space. When the program touches those addresses, the relevant file-backed pages can be faulted into memory and represented through the page cache.
This is another place where the inode, virtual memory, file-backed address space, and page cache meet. The filesystem describes the file, while the virtual-memory system lets the process access cached file contents through memory mappings.
Page Cache And Filesystem Journaling Solve Different Problems
The page cache improves normal file access by retaining file-backed data in RAM. filesystem journaling focuses on recovering filesystem consistency after interrupted metadata updates. They can interact during writes, but they are not the same mechanism.
A page can be dirty because an application changed file data in memory, while the filesystem may also maintain journal transactions for metadata consistency. Storage durability depends on the full stack: application behavior, system calls, cache state, filesystem ordering, journaling, controller behavior, and the physical device.
Direct I/O Can Bypass Normal Page Cache Behavior
Linux also supports specialized I/O paths that can bypass the normal page cache, including forms of direct I/O such as O_DIRECT. Databases and high-performance storage applications may use such mechanisms when they want tighter control over caching or I/O behavior.
That does not make buffered I/O inferior. The page cache is extremely useful for general-purpose workloads because it automatically turns unused RAM into a performance resource without requiring each application to build its own file cache.
Useful Commands For Seeing Memory Cache
free -h
cat /proc/meminfo | grep -E 'Cached|Buffers|Dirty|Writeback'
vmstat 1These commands provide different views of system memory. free -h gives a compact overview, /proc/meminfo exposes more detailed counters, and vmstat helps show changing memory and I/O activity over time.
Do not treat “drop the caches” commands as ordinary optimization. Forcing useful cache out of RAM can make a machine slower and can distort benchmarks. Cache-clearing controls are mainly diagnostic and testing tools when used deliberately.
The Short Version
The Linux page cache uses RAM to hold file-backed data. A cache hit can satisfy a repeated file access from memory instead of storage. Writes can create dirty cached pages that later need writeback. Clean cache can often be reclaimed when applications need memory, which is why low “free” RAM alone does not mean a Linux system is out of memory.
The sentence to remember is: Linux uses spare RAM to avoid unnecessary storage I/O, then reclaims that RAM when more important work needs it.
Editor’s Note
Linux memory-management behavior changes over time, and exact counters or kernel internals can differ by kernel version and workload. This evergreen explains the practical page-cache model rather than prescribing memory-tuning settings for a production system.
BitcoinVersus.Tech is independently maintained. Support options on the site help fund additional technical research, verification, and open educational publishing.
BitcoinVersus.tech is not a financial advisor. Content is provided for informational purposes.
Leave a Reply