Hi Hyeonggon, On Wed, Dec 28, 2022 at 4:49 AM Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx> wrote: > > Hello mm folks, > > I have a few questions about the current status of mmap_lock scalability. > > ============================================================= > What is currently causing the kernel to use mmap_lock to protect the maple tree? > ============================================================= > > I understand that the long-term goal is to remove the need for mmap_lock in readers > while traversing the maple tree, using techniques such as RCU or SPF. > What is the biggest obstacle preventing this from being achieved at this time? Maple tree has an RCU mode which does not need mmap_lock for traversal. Liam and I were testing it recently and Liam fixed a number of issues to enable it. It seems stable now and the fixes are incorporated into the "per-vma locks" patchset which I prepared in this branch: https://github.com/surenbaghdasaryan/linux/tree/per_vma_lock. I haven't posted this patchset upstream yet but it's pretty much ready to go. I'm planning to post it in early January. Thanks, Suren. > > ================================================== > How does the maple tree provide RCU-safe manipulation of VMAs? > ================================================== > > Is it similar to the approach suggested in the RCUVM paper (replacing the original > root node with a new root node that shares most of its nodes and deferring > the freeing of stale nodes using RCU)? > > I'm having difficulty understanding the design of the maple tree in this regard. > > [RCUVM paper] https://pdos.csail.mit.edu/papers/rcuvm:asplos12.pdf > > Thank you for your time. > > --- > Hyeonggon
