From: Rik van Riel <riel@surriel.com>
To: Brendan Jackman <jackmanb@google.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, bp@alien8.de,
peterz@infradead.org, dave.hansen@linux.intel.com,
zhengqi.arch@bytedance.com, nadav.amit@gmail.com,
thomas.lendacky@amd.com, kernel-team@meta.com,
linux-mm@kvack.org, akpm@linux-foundation.org, jannh@google.com,
mhklinux@outlook.com, andrew.cooper3@citrix.com,
Manali Shukla <Manali.Shukla@amd.com>
Subject: Re: [PATCH v9 10/12] x86/mm: do targeted broadcast flushing from tlbbatch code
Date: Mon, 10 Feb 2025 22:45:24 -0500 [thread overview]
Message-ID: <2d20c333400b890f4983cf799576435abf1d8824.camel@surriel.com> (raw)
In-Reply-To: <CA+i-1C2zuctxx6oPVVu0zBJ=Q=Hs73mgrWs5jsp8obARNcUS9g@mail.gmail.com>
On Mon, 2025-02-10 at 16:27 +0100, Brendan Jackman wrote:
> On Thu, 6 Feb 2025 at 05:46, Rik van Riel <riel@surriel.com> wrote:
> > /* Wait for INVLPGB originated by this CPU to complete. */
> > -static inline void tlbsync(void)
> > +static inline void __tlbsync(void)
> > {
> > - cant_migrate();
>
> Why does this have to go away?
I'm not sure the current task in sched_init() has
all the correct bits set to prevent the warning
from firing, but on the flip side it won't have
called INVLPGB yet at that point, so the call to
enter_lazy_tlb() won't actually end up here.
I'll put it back.
>
> > diff --git a/arch/x86/include/asm/tlbflush.h
> > b/arch/x86/include/asm/tlbflush.h
> > index 234277a5ef89..bf167e215e8e 100644
> > --- a/arch/x86/include/asm/tlbflush.h
> > +++ b/arch/x86/include/asm/tlbflush.h
> > @@ -106,6 +106,7 @@ struct tlb_state {
> > * need to be invalidated.
> > */
> > bool invalidate_other;
> > + bool need_tlbsync;
>
> The ifdeffery is missing here.
Added.
>
> > @@ -794,6 +825,8 @@ void switch_mm_irqs_off(struct mm_struct
> > *unused, struct mm_struct *next,
> > if (IS_ENABLED(CONFIG_PROVE_LOCKING))
> > WARN_ON_ONCE(!irqs_disabled());
> >
> > + tlbsync();
> > +
> > /*
> > * Verify that CR3 is what we think it is. This will catch
> > * hypothetical buggy code that directly switches to
> > swapper_pg_dir
> > @@ -973,6 +1006,8 @@ void switch_mm_irqs_off(struct mm_struct
> > *unused, struct mm_struct *next,
> > */
> > void enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk)
> > {
> > + tlbsync();
> > +
>
> I have a feeling I'll look stupid for asking this, but why do we need
> this and the one in switch_mm_irqs_off()?
This is an architectural thing: TLBSYNC waits for
the INVLPGB flushes to finish that were issued
from the same CPU.
That means if we have pending flushes (from the
pageout code), we need to wait for them at context
switch time, before the task could potentially be
migrated to another CPU.
>
> > @@ -1661,12 +1694,53 @@ void arch_tlbbatch_flush(struct
> > arch_tlbflush_unmap_batch *batch)
> > local_irq_enable();
> > }
> >
> > + /*
> > + * If we issued (asynchronous) INVLPGB flushes, wait for
> > them here.
> > + * The cpumask above contains only CPUs that were running
> > tasks
> > + * not using broadcast TLB flushing.
> > + */
> > + if (cpu_feature_enabled(X86_FEATURE_INVLPGB))
>
> It feels wrong that we check the cpufeature here but not in e.g.
> enter_lazy_tlb().
>
> > + tlbsync();
> > +
We no longer need to check it here, with the change
to tlbsync. Good catch.
--
All Rights Reversed.
next prev parent reply other threads:[~2025-02-11 3:50 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-06 4:43 [PATCH v9 00/12] AMD broadcast TLB invalidation Rik van Riel
2025-02-06 4:43 ` [PATCH v9 01/12] x86/mm: make MMU_GATHER_RCU_TABLE_FREE unconditional Rik van Riel
2025-02-07 14:28 ` Brendan Jackman
2025-02-11 11:07 ` Peter Zijlstra
2025-02-11 12:10 ` Brendan Jackman
2025-02-11 20:23 ` Rik van Riel
2025-02-06 4:43 ` [PATCH v9 02/12] x86/mm: remove pv_ops.mmu.tlb_remove_table call Rik van Riel
2025-02-06 4:43 ` [PATCH v9 03/12] x86/mm: consolidate full flush threshold decision Rik van Riel
2025-02-07 14:50 ` Brendan Jackman
2025-02-07 20:22 ` Rik van Riel
2025-02-10 11:15 ` Brendan Jackman
2025-02-10 19:12 ` Rik van Riel
2025-02-06 4:43 ` [PATCH v9 04/12] x86/mm: get INVLPGB count max from CPUID Rik van Riel
2025-02-07 15:10 ` Brendan Jackman
2025-02-07 17:34 ` Brendan Jackman
2025-02-10 7:30 ` Vern Hao
2025-02-10 16:48 ` Rik van Riel
2025-02-12 1:18 ` Vern Hao
2025-02-12 1:57 ` Vern Hao
2025-02-12 15:56 ` Tom Lendacky
2025-02-13 8:16 ` Vern Hao
2025-02-06 4:43 ` [PATCH v9 05/12] x86/mm: add INVLPGB support code Rik van Riel
2025-02-06 4:43 ` [PATCH v9 06/12] x86/mm: use INVLPGB for kernel TLB flushes Rik van Riel
2025-02-07 16:03 ` Brendan Jackman
2025-02-07 20:50 ` Rik van Riel
2025-02-10 11:22 ` Brendan Jackman
2025-02-11 2:01 ` Rik van Riel
2025-02-06 4:43 ` [PATCH v9 07/12] x86/mm: use INVLPGB in flush_tlb_all Rik van Riel
2025-02-06 4:43 ` [PATCH v9 08/12] x86/mm: use broadcast TLB flushing for page reclaim TLB flushing Rik van Riel
2025-02-06 4:43 ` [PATCH v9 09/12] x86/mm: enable broadcast TLB invalidation for multi-threaded processes Rik van Riel
2025-02-10 14:15 ` Brendan Jackman
2025-02-11 3:07 ` Rik van Riel
2025-02-06 4:43 ` [PATCH v9 10/12] x86/mm: do targeted broadcast flushing from tlbbatch code Rik van Riel
2025-02-10 15:27 ` Brendan Jackman
2025-02-11 3:45 ` Rik van Riel [this message]
2025-02-11 10:02 ` Brendan Jackman
2025-02-11 20:21 ` Rik van Riel
2025-02-12 10:38 ` Brendan Jackman
2025-02-06 4:43 ` [PATCH v9 11/12] x86/mm: enable AMD translation cache extensions Rik van Riel
2025-02-06 4:43 ` [PATCH v9 12/12] x86/mm: only invalidate final translations with INVLPGB Rik van Riel
2025-02-06 10:16 ` [PATCH v9 00/12] AMD broadcast TLB invalidation Oleksandr Natalenko
2025-02-06 14:16 ` Rik van Riel
2025-02-06 14:23 ` Peter Zijlstra
2025-02-06 14:48 ` Rik van Riel
2025-02-07 8:16 ` Peter Zijlstra
2025-02-07 17:46 ` Rik van Riel
2025-02-07 18:23 ` Brendan Jackman
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=2d20c333400b890f4983cf799576435abf1d8824.camel@surriel.com \
--to=riel@surriel.com \
--cc=Manali.Shukla@amd.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=jackmanb@google.com \
--cc=jannh@google.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhklinux@outlook.com \
--cc=nadav.amit@gmail.com \
--cc=peterz@infradead.org \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=zhengqi.arch@bytedance.com \
/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