[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFV9xAYLgNljSVem@google.com>
Date: Fri, 20 Jun 2025 08:27:00 -0700
From: Sean Christopherson <seanjc@...gle.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, 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, Jun 19, 2025, Rik van Riel 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.
____cacheline_aligned_in_smp, a.k.a. ____cacheline_aligned, should work in a
struct or "on" a struct. There are multiple instances of both throughout the
kernel.
Powered by blists - more mailing lists