Part II · Your system
17.4 The page cache
alsopage cachecachebuffersdrop cachesdrop_cachesdirty pageswritebacksync
TL;DR
- The page cache keeps file data in RAM after it has been read or written, so the next access doesn't touch the disk.
- It uses spare memory and shrinks by itself when apps need more: there's nothing to free by hand.
- Written data first lands in the cache ("dirty") and reaches the disk
within about 30 seconds;
syncwrites it now.
free -h
grep -E 'Dirty|Writeback' /proc/meminfo
sync
On your machine
$ atfq 17.4 RAM 10.5 GiB available of 15.5 GiB (68%) · 1.1 GiB completely free Cache 7.5 GiB in buff/cache, 604.0 MiB of it shared (tmpfs) Swap 256.0 MiB used of 8.0 GiB · swappiness 60
An example: Alice's laptop, one of the test machines. In your terminal, this block shows your own machine, read live.
Pitfalls
- Emptying the cache (
echo 3 > /proc/sys/vm/drop_caches, as root) is for benchmarks only: the machine is slower afterwards, until it refills. - Pulling out a USB drive right after a copy can lose data still in the
cache: eject it, or run
sync, first. - A big copy can fill RAM with dirty data, then make every program that writes wait while it drains.
- Timing a disk twice in a row times the RAM the second time.
Deep dive 2 questions
How does Linux decide what to drop?
It tells pages used once from pages used again and again, and drops the first kind first. That way one big copy doesn't push out the files you use all the time. Since kernel 6.1, many distros use the multi-generational LRU, a finer version of the same idea.
When does written data reach the disk?
Background writing starts when dirty data passes vm.dirty_background_ratio
(10% of available memory by default), or when it is about 30 seconds old.
Past vm.dirty_ratio (20%), programs that write are made to wait until
enough is on disk.