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

[David Hildenbrand (Arm)]

On 4/29/26 20:19, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
> 
> 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.

> 
> 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.

mm_struct is very likely not a problem.

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.

Maybe on 32bit? Not sure if anybody would really notice.

> I suspect there are some very simple ways to implement the
> per-VMA locks that don't require any additional fields, especially if
> such an approach was limited to SMP=n configs*. For now, do the
> simplest thing: use the same implementation everywhere.
> 
>  * For example, since SMP=n configs don't care much about scalability or
>    false sharing, there could be a single, global VMA seqcount that is
>    bumped when any VMA is modified instead of having space in each VMA
>    for a seqcount.


I'd do that only if we actually determine this to be a problem.


-- 
Cheers,

David