[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YV7+/0+Q1n67wCF8@hirez.programming.kicks-ass.net>
Date: Thu, 7 Oct 2021 16:06:55 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel <linux-kernel@...r.kernel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Borislav Petkov <bp@...e.de>
Subject: Re: [PATCH] x86/apic: reduce cache line misses in
__x2apic_send_IPI_mask()
On Thu, Oct 07, 2021 at 07:04:09AM -0700, Eric Dumazet wrote:
> On Thu, Oct 7, 2021 at 12:29 AM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > On Wed, Oct 06, 2021 at 08:17:56PM -0700, Eric Dumazet wrote:
> > > +/* __x2apic_send_IPI_mask() possibly needs to read
> > > + * x86_cpu_to_logical_apicid for all online cpus in a sequential way.
> > > + * Using per cpu variable would cost one cache line per cpu.
> > > + */
> >
> > Broken comment style..
>
> I was not sure and ran checkpatch.pl before submission, but sure.
>
> >
> > > +static u32 x86_cpu_to_logical_apicid[NR_CPUS] __read_mostly;
> >
> > NR_CPUS is really sad, could this at all be dynamically allocated? Say
> > in x2apic_cluster_probe() ?
>
> Good idea, I will try this.
> Hopefully nr_cpu_ids is populated there ?
Lets hope :-), I'm always terminally lost in early bringup. I figure it
should be painfully obvious if it goes wrong.
Powered by blists - more mailing lists