* Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> [230606 15:20]: > * Yu Ma <yu.ma@xxxxxxxxx> [230606 08:23]: > > UnixBench/Execl represents a class of workload where bash scripts are > > spawned frequently to do some short jobs. When running multiple parallel > > tasks, hot osq_lock is observed from do_mmap and exit_mmap. Both of them > > come from load_elf_binary through the call chain > > "execl->do_execveat_common->bprm_execve->load_elf_binary". In do_mmap,it will > > call mmap_region to create vma node, initialize it and insert it to vma > > maintain structure in mm_struct and i_mmap tree of the mapping file, then > > increase map_count to record the number of vma nodes used. The hot osq_lock > > is to protect operations on file’s i_mmap tree. For the mm_struct member > > change like vma insertion and map_count update, they do not affect i_mmap > > tree. Move those operations out of the lock's critical section, to reduce > > hold time on the lock. > > > > With this change, on Intel Sapphire Rapids 112C/224T platform, based on > > v6.0-rc6, the 160 parallel score improves by 12%. The patch has no > > obvious performance gain on v6.4-rc4 due to regression of this benchmark > > from this commit f1a7941243c102a44e8847e3b94ff4ff3ec56f25 (mm: convert > > mm's rss stats into percpu_counter). > > I didn't think it was safe to insert a VMA into the VMA tree without > holding this write lock? We now have a window of time where a file > mapping doesn't exist for a vma that's in the tree? Is this always > safe? Does the locking order in mm/rmap.c need to change? So I'm pretty sure it's not safe because we've been ensuring that this lock was taken during vma tree inserts since 2002 [1]. Take a look at vma_link() in that commit. I still don't have an answer as to why it's not safe though. [1] https://github.com/mpe/linux-fullhistory/commit/bbbce8f41d3da0ac968bab7a967e12e2be1a7eb0 > > >Related discussion and conclusion > > can be referred at the mail thread initiated by 0day as below: > > Link: https://lore.kernel.org/linux-mm/a4aa2e13-7187-600b-c628-7e8fb108def0@xxxxxxxxx/ > > I don't see a conclusion on that thread talking about changing the > locking order? > > > > > Reviewed-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> > > Signed-off-by: Yu Ma <yu.ma@xxxxxxxxx> > > --- > > mm/mmap.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 13678edaa22c..0e694a0433bc 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -2711,12 +2711,10 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > > if (vma_iter_prealloc(&vmi)) > > goto close_and_free_vma; > > > > - if (vma->vm_file) > > - i_mmap_lock_write(vma->vm_file->f_mapping); > > - > > vma_iter_store(&vmi, vma); > > mm->map_count++; > > if (vma->vm_file) { > > + i_mmap_lock_write(vma->vm_file->f_mapping); > > if (vma->vm_flags & VM_SHARED) > > mapping_allow_writable(vma->vm_file->f_mapping); > > > > -- > > 2.39.3 > > > >
