From: Rik van Riel <riel@surriel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, dave.hansen@linux.intel.com,
luto@kernel.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org
Subject: Re: [PATCH 07/10] x86,mm: enable broadcast TLB invalidation for multi-threaded processes
Date: Sun, 22 Dec 2024 17:45:31 -0500 [thread overview]
Message-ID: <007f3f4f65f9a940106d80b37da977cf2af85a6a.camel@surriel.com> (raw)
In-Reply-To: <20241222113601.GX11133@noisy.programming.kicks-ass.net>
On Sun, 2024-12-22 at 12:36 +0100, Peter Zijlstra wrote:
> On Sat, Dec 21, 2024 at 11:06:39PM -0500, Rik van Riel wrote:
>
> > +/*
> > + * Figure out whether to assign a broadcast (global) ASID to a
> > process.
> > + * We vary the threshold by how empty or full broadcast ASID space
> > is.
> > + * 1/4 full: >= 4 active threads
> > + * 1/2 full: >= 8 active threads
> > + * 3/4 full: >= 16 active threads
> > + * 7/8 full: >= 32 active threads
> > + * etc
> > + *
> > + * This way we should never exhaust the broadcast ASID space, even
> > on very
> > + * large systems, and the processes with the largest number of
> > active
> > + * threads should be able to use broadcast TLB invalidation.
>
> I'm a little confused, at most we need one ASID per CPU, IIRC we have
> something like 4k ASIDs (page-offset bits in the physical address
> bits)
> so for anything with less than 4K CPUs we're good, but with anything
> having more CPUs we're up a creek irrespective of the above scheme,
> no?
We don't need to use broadcast TLB flushing for every
process in the system.
If a system with 8196 CPUs runs a few large processes
(hundreds, or thousands of active CPUs), we want to
ensure those use broadcast TLB flushing with INVLPGB.
We don't really care if some random systemd helper
task ends up being relegated to IPI TLB flushing.
The code is meant to ensure that the tasks where
INVLPGB will help the most are the most likely to
be able to use it.
--
All Rights Reversed.
next prev parent reply other threads:[~2024-12-22 22:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-22 4:06 [RFC PATCH 00/10] AMD broadcast TLB invalidation Rik van Riel
2024-12-22 4:06 ` [PATCH 01/10] Add X86_FEATURE_INVLPGB definition Rik van Riel
2024-12-22 4:06 ` [PATCH 02/10] x86,tlb: get INVLPGB count max from CPUID Rik van Riel
2024-12-22 11:46 ` Borislav Petkov
2024-12-22 14:39 ` Rik van Riel
2024-12-22 4:06 ` [PATCH 03/10] x86,mm: add INVLPGB support code Rik van Riel
2024-12-22 11:05 ` Peter Zijlstra
2024-12-22 21:24 ` Rik van Riel
2024-12-22 4:06 ` [PATCH 04/10] x86,mm: use INVLPGB for kernel TLB flushes Rik van Riel
2024-12-22 11:16 ` Peter Zijlstra
2024-12-22 15:12 ` Rik van Riel
2024-12-24 18:13 ` Peter Zijlstra
2024-12-22 11:47 ` Borislav Petkov
2024-12-22 4:06 ` [PATCH 05/10] x86,tlb: use INVLPGB in flush_tlb_all Rik van Riel
2024-12-22 11:17 ` Peter Zijlstra
2024-12-22 4:06 ` [PATCH 06/10] x86,mm: use broadcast TLB flushing for page reclaim TLB flushing Rik van Riel
2024-12-22 11:18 ` Peter Zijlstra
2024-12-22 4:06 ` [PATCH 07/10] x86,mm: enable broadcast TLB invalidation for multi-threaded processes Rik van Riel
2024-12-22 11:36 ` Peter Zijlstra
2024-12-22 22:45 ` Rik van Riel [this message]
2024-12-22 4:06 ` [PATCH 08/10] x86,tlb: do targeted broadcast flushing from tlbbatch code Rik van Riel
2024-12-22 4:06 ` [PATCH 09/10] x86/mm: enable AMD translation cache extensions Rik van Riel
2024-12-22 11:38 ` Peter Zijlstra
2024-12-22 15:37 ` Rik van Riel
2024-12-24 18:25 ` Peter Zijlstra
2024-12-22 4:06 ` [PATCH 10/10] x86/mm: only invalidate final translations with INVLPGB Rik van Riel
2024-12-22 11:11 ` [RFC PATCH 00/10] AMD broadcast TLB invalidation Peter Zijlstra
2024-12-22 15:06 ` Rik van Riel
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=007f3f4f65f9a940106d80b37da977cf2af85a6a.camel@surriel.com \
--to=riel@surriel.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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
all inboxes | Powered by JetHome®