Re: [PATCH 0/4] move per-vma lock into vm_area_struct

Andrew Morton
2024-11-12T00:11:03Z

On Mon, 11 Nov 2024 15:19:22 -0800 Suren Baghdasaryan <surenb@google.com> wrote:

> On Mon, Nov 11, 2024 at 2:18 PM Davidlohr Bueso <dave@stgolabs.net> wrote:
> >
> > On Mon, 11 Nov 2024, Suren Baghdasaryan wrote:
> >
> > >To minimize memory overhead, vm_lock implementation is changed from
> > >using rw_semaphore (40 bytes) to an atomic (8 bytes) and several
> > >vm_area_struct members are moved into the last cacheline, resulting
> > >in a less fragmented structure:
> >
> > I am not a fan of building a custom lock, replacing a standard one.
>
> Understandable.

If we're going to invent a new lock type, I'm thinking we should do
that - make it a standaline thing, add full lockdep support, etc.

I wonder if we could remove the lock from the vma altogeher and use an
old-fashioned hashed lock. An array of locks indexed by the vma
address. It might work well enough, although sizing the array would be
difficult.