From: Matthew Wilcox <willy@infradead.org>
To: David Hildenbrand <david@redhat.com>
Cc: Suren Baghdasaryan <surenb@google.com>,
akpm@linux-foundation.org, jirislaby@kernel.org,
jacobly.alt@gmail.com, holger@applied-asynchrony.com,
michel@lespinasse.org, jglisse@google.com, mhocko@suse.com,
vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net,
dave@stgolabs.net, liam.howlett@oracle.com, peterz@infradead.org,
ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com,
will@kernel.org, luto@kernel.org, songliubraving@fb.com,
peterx@redhat.com, dhowells@redhat.com, hughd@google.com,
bigeasy@linutronix.de, kent.overstreet@linux.dev,
punit.agrawal@bytedance.com, lstoakes@gmail.com,
peterjung1337@gmail.com, rientjes@google.com,
chriscli@google.com, axelrasmussen@google.com, joelaf@google.com,
minchan@google.com, rppt@kernel.org, jannh@google.com,
shakeelb@google.com, tatashin@google.com, edumazet@google.com,
gthelen@google.com, linux-mm@kvack.org
Subject: Re: [PATCH 1/1] mm: disable CONFIG_PER_VMA_LOCK by default until its fixed
Date: Tue, 4 Jul 2023 14:07:40 +0100 [thread overview]
Message-ID: <ZKQZnAfLRPVqnxiO@casper.infradead.org> (raw)
In-Reply-To: <d47e6507-cfa5-3b88-6318-19d6e015695a@redhat.com>
On Tue, Jul 04, 2023 at 09:18:18AM +0200, David Hildenbrand wrote:
> > At least the reproducer at
> > https://bugzilla.kernel.org/show_bug.cgi?id=217624 is working now. But
> > I wonder if that's the best way to fix this. It's surely simple but
> > locking every VMA is not free and doing that on every fork might
> > regress performance.
>
>
> That would mean that we can possibly still get page faults concurrent to
> fork(), on the yet unprocessed part. While that fixes the issue at hand, I
> cannot reliably tell if this doesn't mess with some other fork() corner
> case.
>
> I'd suggest write-locking all VMAs upfront, before doing any kind of fork-mm
> operation. Just like the old code did. See below.
Calling fork() from a multi-threaded program is fraught with danger.
It's a rare thing to do, and we don't need to optimise for it. It
does, of course, need to not crash. But we can slow it down as much as
we want to. Slowing down single-threaded programs calling fork is
much less acceptable.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html
next prev parent reply other threads:[~2023-07-04 13:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-03 18:21 [PATCH 1/1] mm: disable CONFIG_PER_VMA_LOCK by default until its fixed Suren Baghdasaryan
2023-07-03 20:07 ` David Rientjes
2023-07-03 20:30 ` David Hildenbrand
2023-07-04 5:39 ` Suren Baghdasaryan
2023-07-04 6:50 ` Suren Baghdasaryan
2023-07-04 7:18 ` David Hildenbrand
2023-07-04 7:34 ` Suren Baghdasaryan
2023-07-04 8:03 ` David Hildenbrand
2023-07-04 18:01 ` David Hildenbrand
2023-07-04 13:07 ` Matthew Wilcox [this message]
2023-07-04 17:21 ` Suren Baghdasaryan
2023-07-04 17:36 ` David Hildenbrand
2023-07-04 17:56 ` Suren Baghdasaryan
2023-07-04 18:05 ` David Hildenbrand
2023-07-04 19:11 ` Suren Baghdasaryan
2023-07-04 20:10 ` Suren Baghdasaryan
[not found] ` <7d6ba07b-ee60-8920-b91c-04c826eb4690@applied-asynchrony.com>
2023-07-04 22:03 ` Suren Baghdasaryan
2023-07-04 22:42 ` Matthew Wilcox
[not found] ` <a7149847-4b53-8ff0-d570-042631a1ce20@applied-asynchrony.com>
2023-07-05 6:46 ` Suren Baghdasaryan
2023-07-04 17:55 ` Matthew Wilcox
2023-07-04 17:58 ` Suren Baghdasaryan
2023-07-04 8:12 ` Linux regression tracking (Thorsten Leemhuis)
2023-07-04 8:30 ` Hans de Goede
2023-07-04 8:18 ` Hans de Goede
2023-07-04 15:24 ` Suren Baghdasaryan
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=ZKQZnAfLRPVqnxiO@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=bigeasy@linutronix.de \
--cc=chriscli@google.com \
--cc=dave@stgolabs.net \
--cc=david@redhat.com \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=holger@applied-asynchrony.com \
--cc=hughd@google.com \
--cc=jacobly.alt@gmail.com \
--cc=jannh@google.com \
--cc=jglisse@google.com \
--cc=jirislaby@kernel.org \
--cc=joelaf@google.com \
--cc=kent.overstreet@linux.dev \
--cc=ldufour@linux.ibm.com \
--cc=liam.howlett@oracle.com \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=luto@kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=michel@lespinasse.org \
--cc=minchan@google.com \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterjung1337@gmail.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=punit.agrawal@bytedance.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=shakeelb@google.com \
--cc=songliubraving@fb.com \
--cc=surenb@google.com \
--cc=tatashin@google.com \
--cc=vbabka@suse.cz \
--cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).