On Wed, Oct 27, 2021 at 10:52 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Wed, Oct 27, 2021 at 10:42:29AM -0700, Suren Baghdasaryan wrote: > > On Wed, Oct 27, 2021 at 10:35 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > > > On Wed, Oct 27, 2021 at 09:08:21AM -0700, Suren Baghdasaryan wrote: > > > > Unconditional mmap_write_lock around free_pgtables in exit_mmap seems > > > > to me the most semantically correct way forward and the pushback is on > > > > the basis of regressing performance of the exit path. I would like to > > > > measure that regression to confirm this. I don't have access to a big > > > > machine but will ask someone in another Google team to try the test > > > > Michal wrote here > > > > https://lore.kernel.org/all/20170725142626.GJ26723@xxxxxxxxxxxxxx/ on > > > > a server with and without a custom patch. > > > > > > Sorry to hijack this, but could you ask that team to also test this > > > patch? I think there's probably a good-sized win here, but I have no > > > profiles to share at this point. I've only done light testing, and > > > it may have bugs. > > > > > > NB: I only did the exit() path here. fork() conversion is left as an > > > exercise for the reader^W^W Liam. > > > > To clarify, this patch does not change the mmap_write_lock portion of > > exit_mmap. Do you want to test it in isolation or with the locking > > changes in exit_mmap I mentioned? > > Correct, it does not. I think it's interesting to test it in isolation, > but if you want to test it in in combination, that could also be > interesting (see if we regain some of the expected performance loss). > I just don't have a NUMA box of my own to test on, so I'm hoping to > exploit your test infrastructure ;-) > > By the way, my vmavec patch should also be helpful on small systems > like phones ... ;-) Sounds good. I'll try to queue up the patches so that it's easy to test them both in isolation and together.
