From: Peter Xu <peterx@redhat.com>
To: Khalid Aziz <khalid.aziz@oracle.com>
Cc: akpm@linux-foundation.org, willy@infradead.org,
markhemm@googlemail.com, viro@zeniv.linux.org.uk,
david@redhat.com, mike.kravetz@oracle.com, andreyknvl@gmail.com,
dave.hansen@intel.com, luto@kernel.org, brauner@kernel.org,
arnd@arndb.de, ebiederm@xmission.com, catalin.marinas@arm.com,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, mhiramat@kernel.org, rostedt@goodmis.org,
vasily.averin@linux.dev, xhao@linux.alibaba.com, pcc@google.com,
neilb@suse.de, maz@kernel.org
Subject: Re: [PATCH RFC v2 0/4] Add support for sharing page tables across processes (Previously mshare)
Date: Mon, 12 Jun 2023 12:25:18 -0400 [thread overview]
Message-ID: <ZIdG7rMDY6649hSp@x1n> (raw)
In-Reply-To: <cover.1682453344.git.khalid.aziz@oracle.com>
On Wed, Apr 26, 2023 at 10:49:47AM -0600, Khalid Aziz wrote:
> This patch series adds a new flag to mmap() call - MAP_SHARED_PT.
Since hugetlb has this, it'll be very helpful if you can provide a
comparison between this approach and hugetlb's - especially on the
differences - and reasonings about those.
Merging anything like this definitely should also pave way for hugetlb's
future, so it even seems to be an "requirement" of such patchset even
though implicitily.. considering the "hotness" that hugetlb recently has
on refactoring demand (if not a rewrite).
Some high level questions:
- Why mmap() flag?
For this one, I agree it should be opt-in - sharing pgtable definitely
means sharing of a lot of privileges operating on current mm, so one
should be aware and be prepared to be messed up.
IIUC hugetlb doesn't do this but instead when something "racy" happens
itt just unshares by default. To me opt-in makes more sense if to
start from zero, because I don't think by default a process wants to
leak its mm to others.
I think you mentioned allowing pgtable to be shared even for mprotect()
from one MM then all MMs can see; but if so then DONTNEED should really
do the same - when one MM DONTNEED it it should go away for all. It
doesn't make a lot of sense to me to treat it differently with a
DONTNEED refcount anywhere..
- Can guest MM opt-out?
Should we allow guest MM to opt-out when they want? It sounds like a
good thing to have to me, especially for file that sounds like as
simple as zapping the pgtable. But then mmap flag will stop working
iiuc, so goes back to that question (e.g. what about madvise or prctl?).
- Why mm_struct to represent shared pgtable?
IIUC hugetlb used the pgtable page itself plus some refcounting (the
refcounting is racy with gup-fast that Jann used to point out, but
that's another story..). My question is do you think that won't work?
Are there reasons to explain? Why mm_struct is the structure you chose
for representing a shared pgtable? Why per-file?
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2023-06-12 16:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-26 16:49 [PATCH RFC v2 0/4] Add support for sharing page tables across processes (Previously mshare) Khalid Aziz
2023-04-26 16:49 ` [PATCH RFC v2 1/4] mm/ptshare: Add vm flag for shared PTE Khalid Aziz
2023-04-26 16:49 ` [PATCH RFC v2 2/4] mm/ptshare: Add flag MAP_SHARED_PT to mmap() Khalid Aziz
2023-04-27 11:17 ` kernel test robot
2023-04-29 4:41 ` kernel test robot
2023-04-26 16:49 ` [PATCH RFC v2 3/4] mm/ptshare: Create new mm struct for page table sharing Khalid Aziz
2023-06-26 8:08 ` Karim Manaouil
2023-04-26 16:49 ` [PATCH RFC v2 4/4] mm/ptshare: Add page fault handling for page table shared regions Khalid Aziz
2023-04-27 0:24 ` kernel test robot
2023-04-29 14:07 ` kernel test robot
2023-04-26 21:27 ` [PATCH RFC v2 0/4] Add support for sharing page tables across processes (Previously mshare) Mike Kravetz
2023-04-27 16:40 ` Khalid Aziz
2023-06-12 16:25 ` Peter Xu [this message]
2023-06-30 11:29 ` Rongwei Wang
2023-07-31 4:35 ` Rongwei Wang
2023-07-31 12:25 ` Matthew Wilcox
2023-07-31 12:50 ` David Hildenbrand
2023-07-31 16:19 ` Rongwei Wang
2023-07-31 16:30 ` David Hildenbrand
2023-07-31 16:38 ` Matthew Wilcox
2023-07-31 16:48 ` David Hildenbrand
2023-07-31 16:54 ` Matthew Wilcox
2023-07-31 17:06 ` David Hildenbrand
2023-08-01 6:53 ` Rongwei Wang
2023-08-01 19:28 ` Matthew Wilcox
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=ZIdG7rMDY6649hSp@x1n \
--to=peterx@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=ebiederm@xmission.com \
--cc=khalid.aziz@oracle.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=markhemm@googlemail.com \
--cc=maz@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=neilb@suse.de \
--cc=pcc@google.com \
--cc=rostedt@goodmis.org \
--cc=vasily.averin@linux.dev \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=xhao@linux.alibaba.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.