Re: [PATCH 07/10] x86,mm: enable broadcast TLB invalidation for multi-threaded processes

[Rik van Riel]

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.