Linux usa la funzionalità PCID della CPU x86 per TLB? Se no, perché?

Question

Ho scritto un modulo del kernel per controllare CR4.PCIDE, non è impostato. Perché Linux non usa questa funzionalità per ridurre il rallentamento delle prestazioni a causa dell'invalidità TLB e dell'inquinamento della cache?

Answer 1

Aggiornamento: situazione è cambiata in tutto il 4.15 lasso di tempo a causa del Meltdown and Spectre attacks verso la fine del 2017 e all'inizio del 2018. Vedere the other answer per i dettagli.

Nota: io non sono uno sviluppatore Linux

Per "identificatori di processo contesto" di Intel, c'è un limite di 4096 ID. Ciò significa che quando ci sono più di 4096 processi devi gestirli (ad esempio, magari fare una cosa "usata meno di recente" in modo che se un processo che attualmente non ha un ID deve essere eseguito, l'ID viene preso da alcuni altro processo e riutilizzato).

L'altra cosa che viene in esso è "TLB shootdown" su sistemi multi-CPU. Questi possono essere un po 'costosi, quindi le persone fanno trucchi per evitarli. Ad esempio, se un processo ha solo un thread, può essere eseguito solo su una CPU e si sa che non è necessario inviare un IPI ad altre CPU (interrompendole e chiedendo loro di eseguire il "TLB shootdown"). Una volta che inizi a utilizzare PCIDs non puoi essere sicuro che altre CPU non abbiano ancora voci TLB e non possano fare questi trucchi per evitare "sparatorie TLB". Significa anche che (in teoria, per il supporto PCID mal implementato) le prestazioni ottenute da PCID potrebbero essere inferiori alle prestazioni perse a causa della mancata esecuzione del downdown TLB e della gestione degli ID, con conseguente perdita netta.

Principalmente quello che sto dicendo è che è un po 'complicato aggiungere il supporto per PCID (non è come si può semplicemente impostare un flag in CR4 e non pensarci più). Dovresti fare qualche ricerca (esperimenti, prototipi, benchmarking) per determinare il modo più efficace di implementarlo. Per un kernel grande/complesso/vecchio (come Linux) sarebbe ancora più complicato in quanto dovresti stare attento a non turbare qualcos'altro per sbaglio. L'altra cosa è che questa funzione è relativamente nuova (esiste solo per qualche anno se ricordo bene) e non è supportata da molte CPU (ad esempio, qualcosa di un po 'più vecchio e qualsiasi cosa di AMD).

Fondamentalmente, presumo che si tratti di "tempo contro benefici" (o, non abbastanza tempo per un piccolo miglioramento delle prestazioni su un numero limitato di CPU).

Answer 2

Sì! Le versioni recenti del Kernel Linux hanno il supporto PCID. Al momento della domanda, questo supporto non esisteva, ma è stato aggiunto verso la fine del 2017, a partire dal 4.14 kernel. È possibile seguire alcune delle discussioni di patch originali in this LKML chain.

La modifica non associa in realtà un processo PCID univoco, poiché esiste un numero limitato o tenta di assegnarli a una base utilizzata frequentemente, ma utilizza una cache PCID per CPU, in modo che diversi processi in esecuzione su un è probabile che la CPU sia in grado di utilizzare il meccanismo PCID per evitare l'overhead di svuotamento TLB.

Questo è diventato più rilevante di recente, dal momento che a series of vulnerabilities è stato trovato che consente al codice utente non privilegiato di leggere la memoria del kernel, rispetto alla quale è stato distribuito lo KPTI patches. Queste patch possono avere un impatto significativo sulle prestazioni, poiché le voci TLB a livello utente possono essere invalidate su qualsiasi chiamata del kernel. Con il supporto PCID, l'impatto è ridotto poiché le voci TLB a livello utente vengono mantenute.

---

una versione meno recente di questa risposta si trova in basso, in un momento in cui il supporto PCID non era disponibile nei kernel rilasciati:

Non ancora, ma sembra che qualcosa potrebbe essere in lavori. Vedi la discussione che inizia con around here su LKML. In particolare, vi sono proposte soluzioni ai problemi shootdown trasversale nucleo TLB, tra gli altri:

Se quando ricevono una shootdown TLB per un PCID non corrente, abbiamo appena filo tutte le voci per quel PCID e rimuovere la CPU da di mm cpu_vm_mask_var, non riceveremo mai più di un IPI di ripresa per un mm non corrente, ma otterremo comunque i benefici della longevità del TLB quando si tratta con es. carichi di lavoro di tubazioni in cui le attività eseguono a turno su la stessa CPU.

È inoltre possibile ricavare da quel thread che gli identificatori dello spazio indirizzo sono stati a lungo utilizzati su altre architetture Linux.