The future of the page cache
https://lwn.net/Articles/712467/
- A laptop that can execute 10B instructions/sec can be heavily bottlenecked by cache perf, because memory/MMU can only deliver 500M cache lines/sec (as of 2017)
Unix systems have had a buffer cache, which sits between the filesystem and the disk for the purpose of caching disk blocks in memory, for a long time. While preparing the talk, he went back to look at Sixth-edition Unix (released in 1975) and found a buffer cache there. Linux has had a buffer cache since the beginning. In the 1.3.50 release in 1995, Linus Torvalds added a significant innovation in the form of the page cache. This cache differs from the buffer cache in that it sits between the virtual filesystem (VFS) layer and the filesystem itself. With the page cache, there is no need to call into filesystem code at all if the desired page is present already. Initially, the page and buffer caches were entirely separate, but Ingo Molnar unified them in 1999. Now, the buffer cache still exists, but its entries point into the page cache
- DAX (direct access for files) allows your to bypass the page cache and read/write to block storage directly. Is this similar to O_DIRECT?
There is a spinlock to control access when changes are being made to the page cache, but lookups are handled using the lockless read-copy-update (RCU) mechanism.
When Torvalds wrote the above-mentioned post about the page cache, he said:
It’s also a major disaster from a locking standpoint: trust me, if you think your filesystem can do fine-grained locking right when it comes to things like concurrent lookup of pathnames, you’re living in a dream world.