[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241224181308.GA17252@noisy.programming.kicks-ass.net>
Date: Tue, 24 Dec 2024 19:13:08 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Rik van Riel <riel@...riel.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
dave.hansen@...ux.intel.com, luto@...nel.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, hpa@...or.com,
akpm@...ux-foundation.org
Subject: Re: [PATCH 04/10] x86,mm: use INVLPGB for kernel TLB flushes
On Sun, Dec 22, 2024 at 10:12:56AM -0500, Rik van Riel wrote:
> On Sun, 2024-12-22 at 12:16 +0100, Peter Zijlstra wrote:
> > On Sat, Dec 21, 2024 at 11:06:36PM -0500, Rik van Riel wrote:
> > > Use broadcast TLB invalidation for kernel addresses when available.
> > >
> > > +static void broadcast_kernel_range_flush(unsigned long start,
> > > unsigned long end)
> > > +{
> > > + unsigned long addr;
> > > + unsigned long maxnr = boot_cpu_data.invlpgb_count_max;
> > > + unsigned long threshold = tlb_single_page_flush_ceiling *
> > > maxnr;
> > > +
> > > + /*
> > > + * TLBSYNC only waits for flushes originating on the same
> > > CPU.
> > > + * Disabling migration allows us to wait on all flushes.
> > > + */
> > > + migrate_disable();
> >
> > So how expensive is all this? That is, I think I would feel better is
> > this were preempt_disable().
>
> Either should work. If preempt_disable() is cheaper,
> I'm happy to use that.
I'm not sure about cheaper -- but getting arbitrary scheduling delays in
the middle of TLBi sounds like waaay to much 'fun'.
Powered by blists - more mailing lists