On Tue, Apr 23, 2019 at 05:41:48AM -0700, Matthew Wilcox wrote:
> On Tue, Apr 23, 2019 at 12:47:07PM +0200, Michal Hocko wrote:
> > Well, I believe we should _really_ re-evaluate the range locking sooner
> > rather than later. Why? Because it looks like the most straightforward
> > approach to the mmap_sem contention for most usecases I have heard of
> > (mostly a mm{unm}ap, mremap standing in the way of page faults).
> > On a plus side it also makes us think about the current mmap (ab)users
> > which should lead to an overall code improvements and maintainability.
>
> Dave Chinner recently did evaluate the range lock for solving a problem
> in XFS and didn't like what he saw:
>
> https://lore.kernel.org/linux-fsdevel/20190418031013.GX29573@xxxxxxxxxxxxxxxxxxx/T/#md981b32c12a2557a2dd0f79ad41d6c8df1f6f27c
>
> I think scaling the lock needs to be tied to the actual data structure
> and not have a second tree on-the-side to fake-scale the locking.
Right, which is how I ended up using the split PT locks. They already
provide fine(r) grained locking.
