On Sat, Sep 12, 2020 at 07:39:31PM -0700, Linus Torvalds wrote: > The real worry with (d) is that we are using the page lock for other > things too, not *just* the truncate check. Things where the inode lock > wouldn't be helping, like locking against throwing pages out of the > page cache entirely, or the hugepage splitting/merging etc. It's not > being truncated, it's just the VM shrinking the cache or modifying > things in other ways. Actually, hugepage splitting is done under the protection of page freezing where we temporarily set the refcount to zero, so pagecache lookups spin rather than sleep on the lock. Quite nasty, but also quite rare. > But the page locking code does have some extreme downsides, exactly > because there are so _many_ pages and we end up having to play some The good news is that the THP patchset is making good progress. I have seven consecutive successful three-hour runs of xfstests, so maybe we'll see fewer pages in the future.
