On Mon, Nov 11, 2024 at 4:11 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 11 Nov 2024 15:19:22 -0800 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote: > > > On Mon, Nov 11, 2024 at 2:18 PM Davidlohr Bueso <dave@xxxxxxxxxxxx> 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. Yeah, that will make it easy to experiment and replace it with a different lock type if needed. > > 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. Ok, sounds like I'll need to experiment a bit with different lock implementations. I'll post a new version without the last two patches, keeping rw_semaphore for now. Thanks! >
