From: Mateusz Guzik <mjguzik@gmail.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
David Laight <david.laight.linux@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
oliver.sang@intel.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: avoid use of BIT() macro for initialising VMA flags
Date: Wed, 10 Dec 2025 23:44:48 +0100 [thread overview]
Message-ID: <CAGudoHFcD=Wv=SEqaaks1TcY2CZQsozNzadejQA1uBbdNPSakg@mail.gmail.com> (raw)
In-Reply-To: <0a7b6c7e-c388-4327-b666-6225bc63c90c@lucifer.local>
On Wed, Dec 10, 2025 at 5:18 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> On Tue, Dec 09, 2025 at 10:26:22AM +0100, Mateusz Guzik wrote:
> > On Tue, Dec 09, 2025 at 09:28:10AM +0100, Vlastimil Babka wrote:
> > > As Mateusz pointed out off-list, the profiles look like mutexes are doing
> > > less optimistic spinning and more sleeping. Which IMHO isn't something that
> > > this change can directly affect.
> > >
> >
> > Not mutexes but rwsems.
> >
> > The bench at hand has some of the code spinlocked, other parts take
> > rwsems for reading *or* writing.
> >
> > I had a peek at rwsem implementation and to my understanding it can
> > degrade to no spinning in a microbenchmark setting like this one,
> > provided you are unlucky enough.
>
> So we're just sleep, sleep sleeping? That would explain it...
>
> I mean is this an issue with the IPC design or the rwsem's in general?
>
the ipc code is not doing itself any favors, but is probably not worth
working on either
the lock stuff suffers internal problems. while there is no such thing
as fastest possible lock, let alone sleepable rw lock, it is pretty
clear the current code leaves perf on the table even with that caveat
> >
> > In particular you can get unlucky if existing timings get perturbed,
> > which I presume is happening after Lorenzo's patch.
> >
> > To demonstrate I wrote a toy patch which conditionally converts affected
> > down_read calls into down_write (inlined at the end).
> >
> > While the original report is based on a 192-thread box, I was only able
> > to test with 80 threads. Even so, the crux of the issue was nicely
> > reproduced.
> >
> > ./stress-ng --timeout 10 --times --verify --metrics --no-rand-seed --msg 80
>
> I wonder if large core count matters here in particular, I was doing this
> (albeit in a VM...) with 62 cores
>
you need a large enough count to generate enough contention in the
first place. how much is it for this bench i have no tried figuring
out, even for my hw
next prev parent reply other threads:[~2025-12-10 22:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-05 17:50 Lorenzo Stoakes
2025-12-05 17:52 ` Lorenzo Stoakes
2025-12-05 18:43 ` David Laight
2025-12-05 19:18 ` Lorenzo Stoakes
2025-12-05 21:34 ` David Laight
2025-12-06 16:43 ` Lorenzo Stoakes
2025-12-08 16:42 ` Lorenzo Stoakes
2025-12-08 18:57 ` David Laight
2025-12-09 8:28 ` Vlastimil Babka
2025-12-09 9:26 ` Mateusz Guzik
2025-12-10 16:18 ` Lorenzo Stoakes
2025-12-10 22:44 ` Mateusz Guzik [this message]
2025-12-12 12:24 ` Mateusz Guzik
2025-12-12 13:02 ` David Laight
2025-12-12 13:13 ` Mateusz Guzik
2025-12-12 15:03 ` Lorenzo Stoakes
2025-12-12 17:26 ` Mateusz Guzik
2025-12-05 21:49 ` David Laight
2025-12-06 16:47 ` Lorenzo Stoakes
2025-12-05 19:56 ` John Hubbard
2025-12-06 16:42 ` Lorenzo Stoakes
2025-12-05 20:15 ` Andrew Morton
2025-12-05 20:18 ` David Hildenbrand (Red Hat)
2025-12-06 0:40 ` Stephen Rothwell
2025-12-06 3:12 ` Andrew Morton
2025-12-06 16:35 ` Lorenzo Stoakes
2025-12-06 1:14 ` Al Viro
2025-12-06 1:26 ` Al Viro
2025-12-06 12:35 ` Vlastimil Babka
2025-12-06 16:34 ` Lorenzo Stoakes
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='CAGudoHFcD=Wv=SEqaaks1TcY2CZQsozNzadejQA1uBbdNPSakg@mail.gmail.com' \
--to=mjguzik@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david.laight.linux@gmail.com \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=oliver.sang@intel.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox