To the people who said the Windows source code is needed to understand how it works, hogwash. The file caching in Linux has been doing it this way for years. Windows does it for years as well. It's fairly standard OS caching technique.
Estimating real memory pressure is tough. There's the working set; but the working set may expand when you have sufficient physical memory, even though the marginal performance gains may be small. Similarly, the file system cache may expand when you have sufficient physical memory, but the marginal gains become small there too.
Probably the best unified metric would be the amount of time applications spend blocked on I/O, where that I/O is either paging committed bytes in from disk, or data that would be cacheable - and would have been cached - on a system with more memory. But that's extremely hard to predict.
Committed bytes is completely the wrong metric to appeal to, since it includes pages that have been committed but have never been touched. Windows reserves space for such pages in the page file (it never overcommits), but saying that it leads to "memory pressure" is ridiculous.
An operating system will typically not swap out (or in) cache memory to disk, so, as long as you are exhibiting no swapping behavior, (And you have swap enabled) then you have enough memory. I think it was Adrian Cockroft, in fact, in "Sun Performance and Tuning: Sparc & Solaris" who in fact said that was _the_ way to determine if you have memory pressure on your operating system - run vmstat and watch the si and so column for activity.
Also, predictive prefetching may increase paging in, but in an async fashion, so the application is never actually blocked. This may cause spurious increases in the stats. You need to examine the amount of time threads are actually blocked by the paging behaviour.
Does it _feel_ fast?
