Re: [PATCH RFC v4 0/12] mm: use per-VMA lock in __access_remote_vm for improved monitoring reliability

[Rik van Riel]

On Fri, 2026-09-11 at 17:11 +0200, David Hildenbrand (Arm) wrote:
> On 7/25/26 00:29, Rik van Riel wrote:
> > __access_remote_vm() holds mmap_read_lock() for the whole transfer.
> > On
> > large machines, with large multi-threaded applications, the
> > mmap_lock
> > is often contended, leading to things like reads of
> > /proc/PID/cmdline
> > stalling.
> > 
> > This results in system monitoring tools getting stuck, right when
> > system information would be the most helpful.
> 
> Rik, what's the status of this, and which series do you consider more
> relevant:
> the pure per-VMA lock change or the pure page-table walking + folio
> batching?
> 
> I'd assume the page-table walking would result in more speedup and
> the per-VMA
> in mostly less contention. So likely we'd want the page-table walking
> optimization first.

We can merge them in either order. 

This series gives a speedup as well, by removing 
the double VMA lookup.

If you want to merge the page table walking and
folio batching change first, I can easily rebase
this per-VMA lock series on top of that.

Do you have additional feedback on changes you
want me to make to get the page table walking
and folio batching thing in a merge-ready shape?

-- 
All Rights Reversed.