Re: [PATCH 1/1] mm: disable CONFIG_PER_VMA_LOCK by default until its fixed

[Suren Baghdasaryan <surenb@google.com>]

On Tue, Jul 4, 2023 at 6:07 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> 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.

Hmm. Would you suggest we use different approaches for multi-threaded
vs single-threaded programs?
I think locking VMAs while forking a process which has lots of VMAs
will regress by some amount (we are adding non-zero work). The
question is if that's acceptable or we have to implement something
different. I verified that solution fixes the issue shown by the
reproducer, now I'm trying to quantify this fork performance
regression I suspect we will introduce.

>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html