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!
