Re: [PATCH 09/12] x86/mm: enable broadcast TLB invalidation for multi-threaded processes

[Rik van Riel <riel@surriel.com>]

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.