From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: linux-mm@kvack.org, liam.howlett@oracle.com, willy@infradead.org,
surenb@google.com, ldufour@linux.ibm.com, michel@lespinasse.org,
vbabka@suse.cz, linux-kernel@vger.kernel.org
Subject: [QUESTION] about the maple tree and current status of mmap_lock scalability
Date: Wed, 28 Dec 2022 21:48:51 +0900 [thread overview]
Message-ID: <EC51CFA7-2BC8-4F72-A7D4-3B1A778EDB37@gmail.com> (raw)
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?
==================================================
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
next reply other threads:[~2022-12-28 12:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-28 12:48 Hyeonggon Yoo [this message]
2022-12-28 17:10 ` Suren Baghdasaryan
2022-12-29 11:33 ` Hyeonggon Yoo
2022-12-28 20:50 ` Matthew Wilcox
2022-12-29 14:22 ` Hyeonggon Yoo
2022-12-29 16:51 ` Matthew Wilcox
2022-12-29 17:10 ` Lorenzo Stoakes
2022-12-29 17:21 ` Suren Baghdasaryan
2022-12-29 17:31 ` Matthew Wilcox
2023-01-02 12:04 ` Hyeonggon Yoo
2023-01-02 14:37 ` Matthew Wilcox
2023-02-20 14:26 ` Hyeonggon Yoo
2023-02-20 14:43 ` Matthew Wilcox
2023-02-22 11:38 ` Hyeonggon Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EC51CFA7-2BC8-4F72-A7D4-3B1A778EDB37@gmail.com \
--to=42.hyeyoo@gmail.com \
--cc=ldufour@linux.ibm.com \
--cc=liam.howlett@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=michel@lespinasse.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®