By cache, I assume the writer means disk cache. Disks are slow! (Yes, even your PCIe 4.0 x4 NVMe SSD is.) So the kernel (usually) uses RAM to cache reads and wr

By cache, I assume the writer means disk cache. Disks are slow! (Yes, even your PCIe 4.0 x4 NVMe SSD is.) So the kernel (usually) uses RAM to cache reads and writes. (This can be bypassed, but let's ignore that.) Under heavy disk IO, using fast RAM for this cache is more beneficial than reserving it on behalf of a program that may use it very rarely, or maybe even not at all (in the case of memory leaks)! If on a hypothetical 8GiB RAM system, programs require 6 but 2 of those are rarely used, there is no memory contention but the extra space for disk cache is still a helpful boost. I do think program memory is more valuable on most desktop systems, since commonly memory access is expected to be fast while disk access is expected to be slow. This means that interactive software tends to mitigate for slow IO, while it can't do much against being swapped out. On servers however I'd probably rather let the kernel do its job (at least if I'm focusing on throughput), unexpected slowness may worsen a worst case but the average case is helped enough. Luckily, the Linux kernel, for all of its memory management flaws (don't get me started on overcommit), allows configuring this using the vm.swappiness parameter that tells it what to prioritize.