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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <007f3f4f65f9a940106d80b37da977cf2af85a6a.camel@surriel.com>
Date: Sun, 22 Dec 2024 17:45:31 -0500
From: Rik van Riel <riel@...riel.com>
To: Peter Zijlstra <peterz@...radead.org>
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 07/10] x86,mm: enable broadcast TLB invalidation for
 multi-threaded processes

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.