On Tue, May 26, 2026 at 06:49:44PM -0700, Andrew Morton wrote: > On Thu, 21 May 2026 08:16:01 -0700 Suren Baghdasaryan <[email protected]> > 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/[email protected]/ > > 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
