On Thu, Jun 11, 2026 at 12:11:27PM +0100, Pedro Falcato wrote: > Hi, > > On Thu, Jun 11, 2026 at 02:18:59PM +0800, Huang Shijie wrote: > > In the UnixBench tests, there is a test "execl" which tests > > the execve system call. > > For example, a Hygon's server has 12 NUMA nodes, and 384 CPUs. > > When we test our server with "./Run -c 384 execl", > > the test result is not good enough. The i_mmap locks contended heavily on > > "libc.so" and "ld.so". The i_mmap tree for "libc.so" can be > > over 6000 VMAs, all the VMAs can be in different NUMA mode. The > > insert/remove > > operations do not run quickly enough. > > I _really_ would have appreciated some coordination here, because I said I was > going to take a look at it. I have something that I think is much simpler
Agreed, this is the second (or in fact third?) time in recent weeks that I'm aware of where publicly discussed work has been duplicated with a series that came in later. It's really important, when doing work that impact core stuff to have a look around and see if others are looking at it, as there's nothing more frustrating than to work on something, discuss it publicly, only to find somebody sends a competing series. It can be tricky, as sometimes it's not obvious, or it might not be so easily found, but I would strongly suggest always making an effort on that front. But you didn't even try to send this as an RFC either :) > in practice. These patches are also way too complex to be dropped just before > the merge window. This late in the cycle means -> next cycle. So you'd have needed to resend it at rc1 in a couple weeks anyway. > > Some comments: > > > > > In order to reduce the competition of the i_mmap lock, this patch does > > following: > > 1.) Split the single i_mmap tree into several sibling trees: > > Each tree has a lock. The CONFIG_SPLIT_I_MMAP is used to > > turn on/off this feature. > > There is no need for a config option. This needs to Just Work. Yeah, this is just a no-go. We don't add config options for changes to core rmap code. > > > 2.) Introduce a new field "tree_idx" for vm_area_struct to save the > > sibling tree index for this VMA. > > This is possibly contentious, but there are holes in vm_area_struct. > So I think this is fine. Yeah no thanks for the extra field, I already have plans for those gaps in vm_area_struct. I am in fact writing code right now that uses them... > > > 3.) Introduce a new field "vma_count" for address_space. > > The new mapping_mapped() will use it. > > 4.) Rewrite the vma_interval_tree_foreach() I also intend to send a series that does a bunch of changes in the rmap code that this would conflict with. So let's all coordinate please. > > 5.) Rewrite the lock functions. Yeah looping on file rmap lock/unlock is gross. > > > > After this patch, the VMA insert/remove operations will work faster, > > and we can get over 400% performance improvement with the above test. > > > > Signed-off-by: Huang Shijie <[email protected]> I had a look through and this code is really overwrought and you're putting a bunch of confusing open-coded all over the codebase without comments. This isn't upstreamable quality and you really should have sent this as an RFC first so we could discuss the approach. Thanks, Lorenzo
