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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 4, 2023 at 10:55 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> On Tue, Jul 04, 2023 at 10:21:12AM -0700, Suren Baghdasaryan wrote:
> > On Tue, Jul 4, 2023 at 6:07 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> > > 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.
>
> It might make sense to do that.  Personally, I'd try to quantify it
> with a make -jN build of the kernel.  That workload is fork-heavy of
> single threaded processes, and if it doesn't show much difference, I think
> we're good.

That's a good idea. I wrote a test to mmap large number of vmas and
time the forks but I'll run your suggested test as well. Thanks!





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux