From: Dave Hansen <dave.hansen@intel.com>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Suren Baghdasaryan <surenb@google.com>
Cc: akpm@linux-foundation.org, dave.hansen@linux.intel.com,
Liam.Howlett@oracle.com, david@kernel.org, willy@infradead.org,
shakeel.butt@linux.dev, vbabka@kernel.org, jannh@google.com,
aliceryhl@google.com, arve@android.com, cmllamas@google.com,
christian@brauner.io, tkjos@android.com, dsahern@kernel.org,
davem@davemloft.net, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
netdev@vger.kernel.org
Subject: Re: [PATCH v4 1/5] mm: Make per-VMA locks available universally
Date: Mon, 10 Aug 2026 08:22:41 -0700 [thread overview]
Message-ID: <c8ae7c8d-8fbb-4aaf-8bed-53fdc7dcfcfc@intel.com> (raw)
In-Reply-To: <anmTYW8X6c9TgaO0@lucifer>
On 8/10/26 03:17, Lorenzo Stoakes (ARM) wrote:
> On Thu, Aug 06, 2026 at 01:05:44PM -0700, Suren Baghdasaryan wrote:
...
>> The downside of this is adding some fields to vm_area_struct and
>> mm_struct. There are likely ways to optimize this, especially for
>> things like SMP=n configs. For now, do the simplest thing: use the
>> same implementation everywhere.
>
> I think for most cases SMP=n arches are not going to be scaling too crazily
> on threads/processes anyway.
>
> If real world usecases exist that the struct bloat causes problems for then
> optimisations for those can be looked into.
Yup, totally agree. It's not worth adding complexity and bugs when the
gains would be small.
> But I wonder if cache line alignment would in any case alter the impact of
> this anyway?
Yes, the CONFIG_PER_VMA_LOCK structures are spread across a couple of
spots in vm_area_struct. At least one of them is 4 bytes and another is
____cacheline_aligned_in_smp. I'd eat my hat if there aren't at least a
couple of bytes that could be trimmed.
next prev parent reply other threads:[~2026-08-10 15:22 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 20:05 [PATCH v4 0/5] mm: Unconditional per-VMA locks and cleanups Suren Baghdasaryan
2026-08-06 20:05 ` [PATCH v4 1/5] mm: Make per-VMA locks available universally Suren Baghdasaryan
2026-08-07 15:37 ` Vlastimil Babka (SUSE)
2026-08-08 1:12 ` Matthew Wilcox
2026-08-08 6:08 ` Suren Baghdasaryan
2026-08-10 8:52 ` Lorenzo Stoakes (ARM)
2026-08-10 9:42 ` Lorenzo Stoakes (ARM)
2026-08-10 16:40 ` Suren Baghdasaryan
2026-08-10 10:17 ` Lorenzo Stoakes (ARM)
2026-08-10 15:22 ` Dave Hansen [this message]
2026-08-10 15:56 ` Matthew Wilcox
2026-08-10 17:04 ` Suren Baghdasaryan
2026-08-06 20:05 ` [PATCH v4 2/5] binder: Make shrinker rely solely on per-VMA lock Suren Baghdasaryan
2026-08-07 14:26 ` Alice Ryhl
2026-08-10 10:22 ` Lorenzo Stoakes (ARM)
2026-08-10 18:32 ` Carlos Llamas
2026-08-10 18:54 ` Suren Baghdasaryan
2026-08-10 19:16 ` Carlos Llamas
2026-08-10 21:00 ` Suren Baghdasaryan
2026-08-10 18:57 ` Carlos Llamas
2026-08-06 20:05 ` [PATCH v4 3/5] mm: Add RCU-based VMA lookup helper that waits for writers Suren Baghdasaryan
2026-08-07 15:39 ` Vlastimil Babka (SUSE)
2026-08-08 7:24 ` Matthew Wilcox
2026-08-09 1:07 ` Suren Baghdasaryan
2026-08-10 10:24 ` Lorenzo Stoakes (ARM)
2026-08-10 15:25 ` Dave Hansen
2026-08-08 7:37 ` Matthew Wilcox
2026-08-10 10:41 ` Lorenzo Stoakes (ARM)
2026-08-10 17:07 ` Suren Baghdasaryan
2026-08-06 20:05 ` [PATCH v4 4/5] binder: Remove mmap_lock fallback Suren Baghdasaryan
2026-08-06 20:05 ` [PATCH v4 5/5] tcp: Remove mmap_lock fallback path Suren Baghdasaryan
2026-08-08 7:26 ` Matthew Wilcox
2026-08-09 0:51 ` Suren Baghdasaryan
2026-08-10 15:26 ` Dave Hansen
2026-08-10 17:09 ` Suren Baghdasaryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c8ae7c8d-8fbb-4aaf-8bed-53fdc7dcfcfc@intel.com \
--to=dave.hansen@intel.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=arve@android.com \
--cc=christian@brauner.io \
--cc=cmllamas@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@kernel.org \
--cc=dsahern@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=tkjos@android.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.