Re: [PATCH v2 0/3] use vma locks for proc/pid/{smaps|numa_maps} reads

[Lorenzo Stoakes <ljs@kernel.org>]

On Tue, May 26, 2026 at 06:49:44PM -0700, Andrew Morton wrote:
> On Thu, 21 May 2026 08:16:01 -0700 Suren Baghdasaryan <surenb@google.com> wrote:
>
> > > > It might be but the point of this patchset (and the previous one that
> > > > made a similar change for /proc/pid/maps) is to reduce mmap_lock
> > > > contention, not to speed up the read operation, which is not a
> > > > performance critical part.
> > >
> > > Well, this interface has been around .. forever, so if there is a noticeable
> > > change in performance it should be called out.
> >
> > Sorry, I missed your reply. I'll see if I can adopt Paul's test for
> > /proc/pid/maps [1] for benchmarking smaps but I would expect similar
> > results as was reported in [2].
>
> How's it coming along ;)
>
> > [1] https://github.com/paulmckrcu/proc-mmap_sem-test
> > [2] https://lore.kernel.org/all/20250719182854.3166724-1-surenb@google.com/
>
> I've moved this series to the tail of mm-unstable to permit more time.

Well I'm not sure it's _vital_ to get stats for this, it's pretty much an
extension of existing VMA lock work in /proc/$pid/maps -> smaps, and the
logic is sound.

There's no reason to believe there will be anything other than a reduction
in lock contention here at least under whichever workloads happen to hammer
smaps, but doesn't feel like there's a downside!

Cheers, Lorenzo