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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/11/26 18:03, Rik van Riel wrote:
> 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?

I'll go through one patch set next week, I'm trying to figure out which one to
prioritize :)

-- 
Cheers,

David