Messages in this thread | | | From | Suren Baghdasaryan <> | Date | Wed, 28 Dec 2022 09:10:20 -0800 | Subject | Re: [QUESTION] about the maple tree and current status of mmap_lock scalability |
| |
Hi Hyeonggon,
On Wed, Dec 28, 2022 at 4:49 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> 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
| |