Hi Huang, You seem to be replacing the file rmap altogether here, so you really ought to have sent this as an RFC so we could discuss it as a community first.
Especially so as Pedro had publicly mentioned his plans to implement something similar here, so coordination would have been appreciated. Anyway, as Pedro has pointed out, the code is overly complicated, it's far too configurable (not always a good thing), and the locking implementation is questionable. You seem to be adding a whole bunch of open-coded complexity too, which is not something we want. Abstraction is key for the rmap. You're also not adding any kdoc comments or really many comments at all, and you've not added any tests (though perhaps it's difficult given how core this is). So I would suggest that perhaps any respin should be sent as an RFC so we can engage in that conversation and ensure we're all on the same page? Especially since Pedro plans to send an alternative, simpler, solution I believe. It's also not helpful that you haven't examined the non-NUMA case :) perhaps your particular server behaves a certain way that this approach aids, but regresses other NUMA configurations? We'd really need to be sure of this before accepting invasive changes like this. Thanks, Lorenzo On Thu, Jun 11, 2026 at 02:18:56PM +0800, Huang Shijie wrote: > In NUMA, there are maybe many NUMA nodes and many CPUs. > For example, a Hygon's server has 12 NUMA nodes, and 384 CPUs. > In the UnixBench tests, there is a test "execl" which tests > the execve system call. > > 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". For example, the i_mmap tree for "libc.so" can have > over 6000 VMAs, all the VMAs can be in different NUMA mode. > The insert/remove operations do not run quickly enough. You really need to send detailed, statistically valid numbers across different NUMA configurations for changes like this to be considered. > > patch 1 & patch 2 are try to hide the direct access of i_mmap. > patch 3 splits the i_mmap into sibling trees, each tree has separate lock, > and we can get better performance with this patch set in our NUMA server: > we can get over 400% performance improvement. > > I did not test the non-NUMA case, since I do not have such server. Yeah this isn't a great thing to hear :) you need to demonstrate this doesn't regress non-NUMA machines or NUMA machines of a different configuration. > > v1 --> v2: > Not only split the immap tree, but also split the lock. > v1 : https://lkml.org/lkml/2026/4/13/199 > > Huang Shijie (4): > mm: use mapping_mapped to simplify the code > mm: use get_i_mmap_root to access the file's i_mmap > mm/fs: split the file's i_mmap tree > docs/mm: update document for split i_mmap tree > > Documentation/mm/process_addrs.rst | 63 +++++++--- > arch/arm/mm/fault-armv.c | 3 +- > arch/arm/mm/flush.c | 3 +- > arch/nios2/mm/cacheflush.c | 3 +- > arch/parisc/kernel/cache.c | 4 +- > fs/Kconfig | 8 ++ > fs/dax.c | 3 +- > fs/hugetlbfs/inode.c | 30 +++-- > fs/inode.c | 75 +++++++++++- > include/linux/fs.h | 179 ++++++++++++++++++++++++++++- > include/linux/mm.h | 81 +++++++++++++ > include/linux/mm_types.h | 3 + > kernel/events/uprobes.c | 3 +- > mm/hugetlb.c | 7 +- > mm/internal.h | 3 +- > mm/khugepaged.c | 6 +- > mm/memory-failure.c | 8 +- > mm/memory.c | 8 +- > mm/mmap.c | 11 +- > mm/nommu.c | 28 +++-- > mm/pagewalk.c | 4 +- > mm/rmap.c | 2 +- > mm/vma.c | 74 +++++++++--- > mm/vma_init.c | 3 + > 24 files changed, 534 insertions(+), 78 deletions(-) This is a _lot_ of changes you're making here. It therefore feels like the abstraction is broken somewhat? > > -- > 2.53.0 > > Thanks, Lorenzo
