Re: [PATCH 6/6] mm: Run the fault-around code under the VMA lock

["Yin, Fengwei" <fengwei.yin@intel.com>]

On Tue, 2023-04-04 at 16:23 +0100, Matthew Wilcox wrote:
> On Tue, Apr 04, 2023 at 02:58:50PM +0100, Matthew Wilcox (Oracle)
> wrote:
> > The map_pages fs method should be safe to run under the VMA lock
> > instead
> > of the mmap lock.  This should have a measurable reduction in
> > contention
> > on the mmap lock.
> 
> https://github.com/antonblanchard/will-it-scale/pull/37/files should
> be a good microbenchmark to report numbers from.  Obviously real-
> world
> benchmarks will be more compelling.
> 

Test result in my side with page_fault4 of will-it-scale in thread 
mode is:
  15274196 (without the patch) -> 17291444 (with the patch)

13.2% improvement on a Ice Lake with 48C/96T + 192G RAM + ext4 
filesystem.


The perf showed the mmap_lock contention reduced a lot:
(Removed the grandson functions of do_user_addr_fault()) 

latest linux-next with the patch:
    51.78%--do_user_addr_fault
            |          
            |--49.09%--handle_mm_fault
            |--1.19%--lock_vma_under_rcu
            --1.09%--down_read

latest linux-next without the patch:
    73.65%--do_user_addr_fault
            |          
            |--28.65%--handle_mm_fault
            |--17.22%--down_read_trylock
            |--10.92%--down_read
            |--9.20%--up_read
            --7.30%--find_vma

My understanding is down_read_trylock, down_read and up_read all are
related with mmap_lock. So the mmap_lock contention reduction is quite
obvious.

For functional testing, our 0day already cherry-picked the patchset and
the testing is ongoing. If any problem hit during testing, 0day will
report it out. Thanks.


Regards
Yin, Fengwei