I'm about to go into a philosophical and OS design rat hole:
Embedded systems tend to not have file systems; or if they do, they don't do much file IO. Therefore they don't have buffer cache. General-purpose computers are different: they do file IO. And clean pages in the buffer cache are the best way to "use" memory. Why? Keeping data cached means there is a chance it will be reused. And if a process wants to allocate memory (sbrk and all those system calls), the kernel can give up clean pages instantaneously (I'll give extra details about that in a moment). So if the measurement of "free" measurement does not include clean cache pages, then it should be (near) zero.
And to be 100% clear: This only applies to *CLEAN* pages in the buffer cache (or file system cache), those where an up-to-date copy exists on disk. It does not apply to *DIRTY* pages, which are currently in memory but still have to be written to disk: those can't be instantaneously handed to a process who wants to allocate memory.
Here is a tiny exception: In a multi-threaded or SMP environment, releasing a memory page from clean buffer cache will probably require locking. And thread entry/exit and lock management may require a very small amount of memory. So reserving one extra page (4KB) per thread or per core to guarantee forward progress may be a good idea or even necessary. But that is a tiny amount compared to modern multi-GB machines.
This leaves the (OS-internal) problem of knowing when to write dirty pages back to disk. This is a very difficult compromise. Writing them back too late means too much memory is tied up and can't be used before doing disk IO, which can lead to really bad performance. Writing them back too early means smaller IOs, and needlessly writing the same block multiple times, and can also lead to really bad performance. The art (not science!) of system design is finding the perfect middle ground here, which is quite workload specific.
taiwan740 said:
Also for perspective, my Windows 11 machine has been grinding to a halt lately and paging madly, timing out on key processes. 16GB of DDR5 isn't cutting it anymore.
My FreeBSD server has been running for ~10 or 15 years with 4 GB of memory, using ZFS, and running all the usual network/web services, without ever having any memory constraints. Actually, for much of its life it was only able to use 3 GB (because of i386 architecture). The big difference to your Windows machine? No GUI.
