Estimate page cache size needed to cache a working set of files in RAM.
The Linux page cache transparently keeps recently-read file data in unused RAM, so subsequent reads of the same data are served at RAM speed instead of disk speed — free -h's 'available' and 'cached' columns reflect this. This calculator estimates a simple hit rate as the fraction of your working set that fits in available cache RAM, then blends cache and disk latency by that ratio to estimate effective read latency, illustrating why adding RAM to cache a hot working set often beats upgrading disk speed for read-heavy workloads.
Effective read latency
effective_latency = cache_hit_rate × cache_latency + (1 − cache_hit_rate) × disk_latency
Linux aggressively uses spare RAM for page cache, since cached data can be instantly reclaimed if an application needs the memory. The 'available' column (not 'free') is the number that matters — it accounts for reclaimable cache and represents what's truly available for new allocations.
Only in the sense that cached data isn't pinned — the kernel already reclaims it automatically under memory pressure without any action needed. Manually running `echo 3 > /proc/sys/vm/drop_caches` just discards useful cached data prematurely, typically hurting performance rather than helping it.
Enough RAM (after accounting for application and kernel memory needs) to hold your actively-accessed data — not your total disk usage. A database with a 2TB disk footprint but a 40GB 'hot' working set of frequently queried rows/indexes may perform excellently with just 64GB of RAM.