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.
