linux-kernel - Re: [PATCH 09/12] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <deb660d929578efa81bb5212aca0bfd2d4314a9a.camel@surriel.com>
Date: Mon, 06 Jan 2025 11:03:22 -0500
From: Rik van Riel <riel@...riel.com>
To: Nadav Amit <nadav.amit@...il.com>
Cc: the arch/x86 maintainers <x86@...nel.org>, Linux Kernel Mailing List	
 <linux-kernel@...r.kernel.org>, kernel-team@...a.com, Dave Hansen	
 <dave.hansen@...ux.intel.com>, luto@...nel.org, peterz@...radead.org,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, "H. Peter Anvin"	 <hpa@...or.com>, Andrew
 Morton <akpm@...ux-foundation.org>, 	zhengqi.arch@...edance.com, "open
 list:MEMORY MANAGEMENT" <linux-mm@...ck.org>
Subject: Re: [PATCH 09/12] x86/mm: enable broadcast TLB invalidation for
 multi-threaded processes

On Mon, 2025-01-06 at 16:52 +0200, Nadav Amit wrote:
> 
> 
> I thought about it further and I am not sure this approach is so
> great.
> It reminds me the technique of eating chocolate forever: each day eat
> half of the previous day. It works in theory, but less in practice.
> 
The PCID space might be just large enough that we can
get away with it, even on extremely large systems.

Say that we have a system with 8192 CPUs, where we are
not using the PTI mitigation, giving us 4086 or so available
PCIDs.

If the system runs 4k 2-thread processes, most of them
get to use INVLPGB.

If the system runs 4 processes with 2k threads each, all
of those large processes get to use INVLPGB.

If a few smaller processes do not get to use INVLPGB,
it may not matter much, since the large (and presumably
more important) processes in the system do get to use it.

> IOW, I mean it seems likely that early processes would get and hog
> all
> broadcast ASIDs. It seems necessary to be able to revoke broadcast
> ASIDs,
> although I understand it can be complicated.
> 

Revoking broadcast ASIDs works. An earlier prototype of
these patches assigned broadcast ASIDs only to the top
8 TLB flushing processes on the system, and would kick
tasks out of the top 8 when a more active flusher showed
up.

However, given that INVLPGB seems to give only a few
percent performance boost in the Phoronix tests, having
some processes use INVPLGB, and some use TLB flushing
might be a perfectly reasonable fallback.

https://www.phoronix.com/news/AMD-INVLPGB-Linux-Benefits

-- 
All Rights Reversed.