[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250623115019.6a750e10@pumpkin>
Date: Mon, 23 Jun 2025 11:50:19 +0100
From: David Laight <david.laight.linux@...il.com>
To: Rik van Riel <riel@...riel.com>
Cc: Nadav Amit <nadav.amit@...il.com>, linux-kernel@...r.kernel.org,
kernel-team@...a.com, dave.hansen@...ux.intel.com, luto@...nel.org,
peterz@...radead.org, bp@...en8.de, x86@...nel.org, seanjc@...gle.com,
tglx@...utronix.de, mingo@...nel.org, Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [RFC PATCH v4 5/8] x86/mm: Introduce Remote Action Request
On Thu, 19 Jun 2025 21:10:47 -0400
Rik van Riel <riel@...riel.com> wrote:
> On Fri, 2025-06-20 at 02:01 +0300, Nadav Amit wrote:
> >
> > > +/*
> > > + * Reduce contention for the RAR payloads by having a small number
> > > of
> > > + * CPUs share a RAR payload entry, instead of a free for all with
> > > all CPUs.
> > > + */
> > > +struct rar_lock {
> > > + union {
> > > + raw_spinlock_t lock;
> > > + char __padding[SMP_CACHE_BYTES];
> > > + };
> > > +};
> >
> > I think you can lose the __padding and instead have
> > ____cacheline_aligned (and then you won't need union).
> >
> I tried that initially, but the compiler was unhappy
> to have __cacheline_aligned in the definition of a
> struct.
You should be able to put it onto the first structure member.
(Which would match the normal use.)
The padding doesn't have the same effect.
Even for rar_lock[] the first entry will share with whatever
comes before, and the padding on the last entry just isn't used.
David
Powered by blists - more mailing lists