Re: [PATCH 1/6] mm: Make per-VMA locks available universally

[Lorenzo Stoakes <ljs@kernel.org>]

On Fri, May 08, 2026 at 12:58:35PM +0200, David Hildenbrand (Arm) wrote:
> On 5/8/26 12:12, David Hildenbrand (Arm) wrote:
> > On 4/29/26 20:19, Dave Hansen wrote:
> >> From: Dave Hansen <dave.hansen@linux.intel.com>
> >>
> >> The per-VMA locks have been around for several years. They've had some
> >> bugs worked out of them and have seen quite wide use. However, they
> >> are still only available when architectures explicitly enable them.
> >> Remove the conditional compilation around the per-VMA locks, making
> >> them available on all architectures and configs.
> >
> > Yes, we should really just make it now just a fixed part of the kernel design.

Agreed

> >
> >>
> >> The approach up to now seemed to be to add ARCH_SUPPORTS_PER_VMA_LOCK
> >> when the architecture started using per-VMA locks in the fault
> >> handler. But, contrary to the naming, the Kconfig option does not
> >> really indicate whether the architecture supports per-VMA locks or
> >> not. It is more of a marker for whether the architecture is likely to
> >> benefit from per-VMA locks.
> >>
> >> To me, the most important thing side-effect of universal availability
> >> is letting per-VMA locks be used in SMP=n configs. This lets us use
> >> per-VMA locking in all x86 code without fallbacks.
> >>
> >> Overall, this just generally makes the kernel simpler. Just look at
> >> the diffstat. It also opens the door to users that want to use the
> >> per-VMA locks in common code. Doing *that* can bring additional
> >> simplifications.
> >>
> >> The downside of this is adding some fields to vm_area_struct and
> >> mm_struct.
> >
> > I'd assume most distributions would already enable it.

Yes, and I think any modern system will treat it as a necessity!

> >
> > mm_struct is very likely not a problem.

No not at all that's a lost cause :)) But also less improtant as less
propagated, obviously.

> >
> > On x86-64, the smallest size for vma_area_struct possible (make allnoconfig)
> > seems to be 68bytes. The largest size (make allyesconfig) with lockdep and all
> > that is 256bytes. Without lockdep we are at 192 bytes: independent of per-VMA locks.
> >
> > I'd expect that on most 64bit configs we usually end up with 192 bytes today.
> >
> > Given that our slab sizes are ...32/64/96/128/192/..., I guess we'd have to be
> > lucky to jump between sizes on most configs.
>
> As Vlastimil reminded me, the have separate slab caches, so they are better
> packed. So I don't think a small increase there would really be a problem.

Good to have this information also!

>
> --
> Cheers,
>
> David

Cheers, Lorenzo