From: Rik van Riel <riel@surriel.com>
To: Dave Hansen <dave.hansen@intel.com>, x86@kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org,
nadav.amit@gmail.com, zhengqi.arch@bytedance.com,
linux-mm@kvack.org
Subject: Re: [PATCH 06/12] x86/mm: use INVLPGB for kernel TLB flushes
Date: Fri, 10 Jan 2025 00:31:23 -0500 [thread overview]
Message-ID: <1409344951af9427799bd28d7865c9ea7fa87ed3.camel@surriel.com> (raw)
In-Reply-To: <426011a9-1fbc-415c-bac7-df5d67417df3@intel.com>
On Thu, 2025-01-09 at 13:18 -0800, Dave Hansen wrote:
>
> But actually I think INVLPGB is *WAY* better than INVLPG here.
> INVLPG
> doesn't have ranged invalidation. It will only architecturally
> invalidate multiple 4K entries when the hardware fractured them in
> the
> first place. I think we should probably take advantage of what
> INVLPGB
> can do instead of following the INVLPG approach.
>
> INVLPGB will invalidate a range no matter where the underlying
> entries
> came from. Its "increment the virtual address at the 2M boundary"
> mode
> will invalidate entries of any size. That's my reading of the docs at
> least. Is that everyone else's reading too?
Ohhhh, good point! I glossed over that the first
half dozen times I was reading the document, because
I was trying to use the ASID, and working to figure
out why things kept crashing (turns out I can only
use the PCID on bare metal)
>
> So, let's pick a number "Z" which is >= invlpgb_count_max. Z could
> arguably be set to tlb_single_page_flush_ceiling. Then do this:
>
> 4k -> Z*4k => use 4k step
> >Z*4k -> Z*2M => use 2M step
> >Z*2M => invalidate everything
>
> Invalidations <=Z*4k are exact. They never zap extra TLB entries.
>
> Invalidations that use the 2M step *might* unnecessarily zap some
> extra
> 4k mappings in the last 2M, but this is *WAY* better than
> invalidating
> everything.
>
This is a great idea.
Then the code in get_flush_tlb_info can adjust
start, end, and stride_shift as needed.
INVLPGB also supports invalidation of an entire
1GB region, so we can take your idea one step
further :)
With up to 8 pages zapped by a single INVLPGB
instruction, and multiple in flight simultaneously,
maybe we could set the threshold to 64, for 8
INVLPGBs in flight at once?
That way we can invalidate up to 1/8th of a
512 entry range with individual zaps, before
just zapping the higher level entry.
> "Invalidate everything" obviously stinks, but it should only be for
> pretty darn big invalidations.
That would only come into play when we get
past several GB worth of invalidation.
--
All Rights Reversed.
next prev parent reply other threads:[~2025-01-10 5:32 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-30 17:53 [PATCH v3 00/12] AMD broadcast TLB invalidation Rik van Riel
2024-12-30 17:53 ` [PATCH 01/12] x86/mm: make MMU_GATHER_RCU_TABLE_FREE unconditional Rik van Riel
2024-12-30 18:41 ` Borislav Petkov
2024-12-31 16:11 ` Rik van Riel
2024-12-31 16:19 ` Borislav Petkov
2024-12-31 16:30 ` Rik van Riel
2025-01-02 11:52 ` Borislav Petkov
2025-01-02 19:56 ` Peter Zijlstra
2025-01-03 12:18 ` Borislav Petkov
2025-01-04 16:27 ` Peter Zijlstra
2025-01-06 15:54 ` Dave Hansen
2025-01-06 15:47 ` Rik van Riel
2024-12-30 17:53 ` [PATCH 02/12] x86/mm: remove pv_ops.mmu.tlb_remove_table call Rik van Riel
2024-12-31 3:18 ` Qi Zheng
2024-12-30 17:53 ` [PATCH 03/12] x86/mm: add X86_FEATURE_INVLPGB definition Rik van Riel
2025-01-02 12:04 ` Borislav Petkov
2025-01-03 18:27 ` Rik van Riel
2025-01-03 21:07 ` Borislav Petkov
2024-12-30 17:53 ` [PATCH 04/12] x86/mm: get INVLPGB count max from CPUID Rik van Riel
2025-01-02 12:15 ` Borislav Petkov
2025-01-10 18:44 ` Tom Lendacky
2025-01-10 20:27 ` Rik van Riel
2025-01-10 20:31 ` Tom Lendacky
2025-01-10 20:34 ` Borislav Petkov
2024-12-30 17:53 ` [PATCH 05/12] x86/mm: add INVLPGB support code Rik van Riel
2025-01-02 12:42 ` Borislav Petkov
2025-01-06 16:50 ` Dave Hansen
2025-01-06 17:32 ` Rik van Riel
2025-01-06 18:14 ` Borislav Petkov
2025-01-14 19:50 ` Rik van Riel
2025-01-03 12:44 ` Borislav Petkov
2024-12-30 17:53 ` [PATCH 06/12] x86/mm: use INVLPGB for kernel TLB flushes Rik van Riel
2025-01-03 12:39 ` Borislav Petkov
2025-01-06 17:21 ` Dave Hansen
2025-01-09 20:16 ` Rik van Riel
2025-01-09 21:18 ` Dave Hansen
2025-01-10 5:31 ` Rik van Riel [this message]
2025-01-10 6:07 ` Nadav Amit
2025-01-10 15:14 ` Dave Hansen
2025-01-10 16:08 ` Rik van Riel
2025-01-10 16:29 ` Dave Hansen
2025-01-10 16:36 ` Rik van Riel
2025-01-10 18:53 ` Tom Lendacky
2025-01-10 20:29 ` Rik van Riel
2024-12-30 17:53 ` [PATCH 07/12] x86/tlb: use INVLPGB in flush_tlb_all Rik van Riel
2025-01-06 17:29 ` Dave Hansen
2025-01-06 17:35 ` Rik van Riel
2025-01-06 17:54 ` Dave Hansen
2024-12-30 17:53 ` [PATCH 08/12] x86/mm: use broadcast TLB flushing for page reclaim TLB flushing Rik van Riel
2024-12-30 17:53 ` [PATCH 09/12] x86/mm: enable broadcast TLB invalidation for multi-threaded processes Rik van Riel
2024-12-30 19:24 ` Nadav Amit
2025-01-01 4:42 ` Rik van Riel
2025-01-01 15:20 ` Nadav Amit
2025-01-01 16:15 ` Karim Manaouil
2025-01-01 16:23 ` Rik van Riel
2025-01-02 0:06 ` Nadav Amit
2025-01-03 17:36 ` Jann Horn
2025-01-04 2:55 ` Rik van Riel
2025-01-06 13:04 ` Jann Horn
2025-01-06 14:26 ` Rik van Riel
2025-01-06 14:52 ` Nadav Amit
2025-01-06 16:03 ` Rik van Riel
2025-01-06 18:40 ` Dave Hansen
2025-01-12 2:36 ` Rik van Riel
2024-12-30 17:53 ` [PATCH 10/12] x86,tlb: do targeted broadcast flushing from tlbbatch code Rik van Riel
2024-12-30 17:53 ` [PATCH 11/12] x86/mm: enable AMD translation cache extensions Rik van Riel
2024-12-30 18:25 ` Nadav Amit
2024-12-30 18:27 ` Rik van Riel
2025-01-03 17:49 ` Jann Horn
2025-01-04 3:08 ` Rik van Riel
2025-01-06 13:10 ` Jann Horn
2025-01-06 18:29 ` Sean Christopherson
2025-01-10 19:34 ` Tom Lendacky
2025-01-10 19:45 ` Rik van Riel
2025-01-10 19:58 ` Borislav Petkov
2025-01-10 20:43 ` Rik van Riel
2024-12-30 17:53 ` [PATCH 12/12] x86/mm: only invalidate final translations with INVLPGB Rik van Riel
2025-01-03 18:40 ` Jann Horn
2025-01-12 2:39 ` Rik van Riel
2025-01-06 19:03 ` [PATCH v3 00/12] AMD broadcast TLB invalidation Dave Hansen
2025-01-12 2:46 ` Rik van Riel
2025-01-06 22:49 ` Yosry Ahmed
2025-01-07 3:25 ` Rik van Riel
2025-01-08 1:36 ` Yosry Ahmed
2025-01-09 2:25 ` Andrew Cooper
2025-01-09 2:47 ` Andrew Cooper
2025-01-09 21:32 ` Yosry Ahmed
2025-01-09 23:00 ` Andrew Cooper
2025-01-09 23:26 ` Yosry Ahmed
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=1409344951af9427799bd28d7865c9ea7fa87ed3.camel@surriel.com \
--to=riel@surriel.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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