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.
