From: Matthew Wilcox <willy@infradead.org>
To: Peter Xu <peterx@redhat.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Lokesh Gidra <lokeshgidra@google.com>,
Alistair Popple <apopple@nvidia.com>
Subject: Re: [PATCH] mm: Always sanity check anon_vma first for per-vma locks
Date: Fri, 12 Apr 2024 04:14:16 +0100 [thread overview]
Message-ID: <ZhinCD-PoblxGFm0@casper.infradead.org> (raw)
In-Reply-To: <Zhhd-A7w1A8JUadM@casper.infradead.org>
On Thu, Apr 11, 2024 at 11:02:32PM +0100, Matthew Wilcox wrote:
> > How many instructions it takes for a late RETRY for WRITEs to private file
> > mappings, fallback to mmap_sem?
>
> Doesn't matter. That happens _once_ per VMA, and it's dwarfed by the
> cost of allocating and initialising the COWed page. You're adding
> instructions to every single page fault. I'm not happy that we had to
> add extra instructions to the fault path for single-threaded programs,
> but we at least had the justification that we were improving scalability
> on large systems. Your excuse is "it makes the code cleaner". And
> honestly, I don't think it even does that.
Suren, what would you think to this?
diff --git a/mm/memory.c b/mm/memory.c
index 6e2fe960473d..e495adcbe968 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5821,15 +5821,6 @@ struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,
if (!vma_start_read(vma))
goto inval;
- /*
- * find_mergeable_anon_vma uses adjacent vmas which are not locked.
- * This check must happen after vma_start_read(); otherwise, a
- * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
- * from its anon_vma.
- */
- if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
- goto inval_end_read;
-
/* Check since vm_start/vm_end might change before we lock the VMA */
if (unlikely(address < vma->vm_start || address >= vma->vm_end))
goto inval_end_read;
That takes a few insns out of the page fault path (good!) at the cost
of one extra trip around the fault handler for the first fault on an
anon vma. It makes the file & anon paths more similar to each other
(good!)
We'd need some data to be sure it's really a win, but less code is
always good.
We could even eagerly initialise vma->anon_vma for anon vmas. I don't
know why we don't do that.
next prev parent reply other threads:[~2024-04-12 3:14 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 17:06 Peter Xu
2024-04-10 20:26 ` Matthew Wilcox
[not found] ` <Zhb6B8UsidEEbFu3@x1n>
2024-04-10 21:10 ` Matthew Wilcox
2024-04-10 21:23 ` Peter Xu
2024-04-10 23:59 ` Matthew Wilcox
2024-04-11 0:20 ` Peter Xu
2024-04-11 14:50 ` Matthew Wilcox
2024-04-11 15:34 ` Peter Xu
2024-04-11 17:14 ` Matthew Wilcox
2024-04-11 15:42 ` Suren Baghdasaryan
2024-04-11 17:13 ` Liam R. Howlett
[not found] ` <ZhhSItiyLYBEdAX3@x1n>
2024-04-11 21:27 ` Matthew Wilcox
2024-04-11 21:46 ` Peter Xu
2024-04-11 22:02 ` Matthew Wilcox
2024-04-12 3:14 ` Matthew Wilcox [this message]
2024-04-12 12:38 ` Peter Xu
2024-04-12 13:06 ` Suren Baghdasaryan
2024-04-12 14:16 ` Matthew Wilcox
2024-04-12 14:53 ` Suren Baghdasaryan
2024-04-12 15:19 ` Matthew Wilcox
2024-04-12 15:31 ` Matthew Wilcox
2024-04-13 21:46 ` Suren Baghdasaryan
2024-04-13 22:52 ` Matthew Wilcox
2024-04-13 23:11 ` Suren Baghdasaryan
2024-04-13 21:41 ` Suren Baghdasaryan
2024-04-13 22:46 ` Matthew Wilcox
2024-04-15 15:58 ` Suren Baghdasaryan
2024-04-15 16:13 ` Matthew Wilcox
2024-04-15 16:19 ` Suren Baghdasaryan
2024-04-15 16:26 ` Matthew Wilcox
2024-04-12 12:46 ` Suren Baghdasaryan
2024-04-12 13:32 ` Matthew Wilcox
2024-04-12 13:46 ` Suren Baghdasaryan
2024-04-26 14:00 ` Matthew Wilcox
2024-04-26 15:07 ` Suren Baghdasaryan
2024-04-26 15:28 ` Matthew Wilcox
2024-04-26 15:32 ` Suren Baghdasaryan
2024-04-26 15:50 ` Matthew Wilcox
2024-04-26 15:32 ` Liam R. Howlett
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=ZhinCD-PoblxGFm0@casper.infradead.org \
--to=willy@infradead.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lokeshgidra@google.com \
--cc=peterx@redhat.com \
--cc=surenb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox