On Fri, Apr 18, 2025 at 10:50 AM Suren Baghdasaryan <sur...@google.com> wrote: > > Utilize speculative vma lookup to find and snapshot a vma without > taking mmap_lock during PROCMAP_QUERY ioctl execution. Concurrent > address space modifications are detected and the lookup is retried. > While we take the mmap_lock for reading during such contention, we > do that momentarily only to record new mm_wr_seq counter.
PROCMAP_QUERY is an even more obvious candidate for fully lockless speculation, IMO (because it's more obvious that vma's use is localized to do_procmap_query(), instead of being spread across m_start/m_next and m_show as with seq_file approach). We do rcu_read_lock(), mmap_lock_speculate_try_begin(), query for VMA (no mmap_read_lock), use that VMA to produce (speculative) output, and then validate that VMA or mm_struct didn't change with mmap_lock_speculate_retry(). If it did - retry, if not - we are done. No need for vma_copy and any gets/puts, no? > This change is designed to reduce mmap_lock contention and prevent > PROCMAP_QUERY ioctl calls (often a low priority task, such as > monitoring/data collection services) from blocking address space > updates. > > Signed-off-by: Suren Baghdasaryan <sur...@google.com> > --- > fs/proc/task_mmu.c | 63 ++++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 55 insertions(+), 8 deletions(-) > [...]
