Cosa succede ai contenuti della cache su un cambio di contesto?


50

In un processore multicore, cosa succede al contenuto della cache di un core (diciamo L1) quando si verifica un cambio di contesto su quella cache?

Il comportamento dipende dall'architettura o è un comportamento generale seguito da tutti i produttori di chip?

Risposte:


42

Ciò dipende sia dal processore (non solo dalla serie di processori, può variare da modello a modello) sia dai sistemi operativi, ma esistono principi generali. Se un processore è multicore non ha alcun impatto diretto su questo aspetto; lo stesso processo potrebbe essere eseguito su più core contemporaneamente (se è multithread) e la memoria può essere condivisa tra i processi, quindi la sincronizzazione della cache è inevitabile indipendentemente da ciò che accade su un cambio di contesto.

Quando un processore cerca una posizione di memoria nella cache, se esiste una MMU , può usare l'indirizzo fisico o virtuale di quella posizione (a volte anche una combinazione di entrambi, ma qui non è rilevante).

Con gli indirizzi fisici, non importa quale processo acceda all'indirizzo, i contenuti possono essere condivisi. Pertanto non è necessario invalidare il contenuto della cache durante un cambio di contesto. Se i due processi associano la stessa pagina fisica con attributi diversi, questo viene gestito dalla MMU (che funge da MPU (unità di protezione della memoria)). L'aspetto negativo di una cache indirizzata fisicamente è che la MMU deve trovarsi tra il processore e la cache, quindi la ricerca della cache è lenta. Le cache L1 non sono quasi mai indirizzi fisici; cache di livello superiore possono essere.

Lo stesso indirizzo virtuale può indicare posizioni di memoria diverse in processi diversi. Quindi, con una cache praticamente indirizzata, il processore e il sistema operativo devono cooperare per garantire che un processo trovi la memoria giusta. Esistono diverse tecniche comuni. Il codice di cambio di contesto fornito dal sistema operativo può invalidare l'intera cache; questo è corretto ma molto costoso. Alcune architetture della CPU hanno spazio nella loro riga della cache per un ASID (identificatore dello spazio degli indirizzi), la versione hardware di un ID processo, utilizzata anche dalla MMU. Ciò separa efficacemente le voci della cache da diversi processi e significa che due processi che mappano la stessa pagina avranno viste incoerenti della stessa pagina fisica (di solito c'è un valore ASID speciale che indica una pagina condivisa, ma questi devono essere scaricati se non sono mappati allo stesso indirizzo in tutti i processi in cui sono mappati). Se il sistema operativo fa in modo che processi diversi utilizzino spazi di indirizzi non sovrapposti (il che vanifica alcuni degli scopi dell'utilizzo della memoria virtuale, ma a volte può essere fatto), le righe della cache rimangono valide.

La maggior parte dei processori che hanno una MMU hanno anche un TLB . TLB è una cache di mapping da indirizzi virtuali a indirizzi fisici. Il TLB viene consultato prima delle ricerche nelle cache indirizzate fisicamente, per determinare rapidamente l'indirizzo fisico quando possibile; il processore può avviare la ricerca della cache prima che la ricerca TLB sia completa, poiché spesso le righe della cache candidate possono essere identificate dai bit centrali dell'indirizzo, tra i bit che determinano l'offset in una riga della cache e i bit che determinano la pagina. Le cache praticamente indirizzate ignorano il TLB in caso di hit della cache, sebbene il processore possa avviare la ricerca TLB mentre sta eseguendo una query nella cache, in caso di errore.

Lo stesso TLB deve essere gestito durante un cambio di contesto. Se le voci TLB contengono un ASID, possono rimanere in posizione; il sistema operativo deve svuotare le voci TLB solo se il loro ASID ha cambiato significato (ad es. perché è uscito un processo). Se le voci TLB sono globali, devono essere invalidate quando si passa a un contesto diverso.


2
Molto informativo. Se potessi aggiungere alcuni esempi di come ciò avviene nelle architetture reali, sarebbe ancora meglio.
JohnTortugo,

2
@JohnTortugo Quello che ho scritto corrisponde abbastanza da vicino a ciò che puoi fare su ARMv7 (ad esempio la CPU del tuo smartphone) (l'unica architettura in cui abbia mai scritto il codice di gestione MMU). Mi aspetto che altre piattaforme come x86 siano abbastanza simili ma non potrei scriverne. Se stai cercando informazioni concrete su una vera piattaforma, Computer Science non è il sito giusto, potresti chiedere su Stack Overflow o Electrical Engineering o Embeddedd (proposto) .
Gilles 'SO- smetti di essere malvagio' il

10

La cache è in genere ignara di un cambio di contesto. Solo la sequenza di indirizzi di memoria a cui si accede determina quali righe della cache vengono sostituite.

La politica di sostituzione di solito è euristica dipendente dal produttore e dalla particolare microarchitettura. Il problema è che l'euristica non può prevedere il futuro, a quale indirizzo e quindi alla riga della cache si accederà successivamente.

L'euristica può essere semplice come LRU (utilizzata meno di recente). Ma con le moderne CPU l'euristica è più complessa.

Dai un'occhiata al Manuale per gli sviluppatori del software Intel® 64 e IA-32 Architectures Volume 3 Il capitolo 11 spiega la cache di memoria e i meccanismi di controllo della cache. AMD ha questo nel capitolo 7 del Manuale del programmatore dell'architettura AMD64 Volume 2: Programmazione del sistema . Per le CPU basate su ARM sembra che i PDF siano disponibili solo per i clienti registrati.


Puoi fornire un riferimento per il primo paragrafo? O i documenti collegati fanno riferimento a questo problema?
Raffaello

Il comportamento dipende fortemente dal fatto che la cache sia indirizzata fisicamente o virtualmente. La politica di sostituzione non è pertinente qui. Per ARM, ci sono informazioni nei manuali tecnici del processore, che sono pubblici, ad esempio L1 su Cortex-A9 (cosa si ottiene nei telefoni cellulari di ultima generazione), anche se può essere difficile da capire senza il manuale di riferimento dell'architettura non pubblica .
Gilles 'SO- smetti di essere cattivo' il

1
@Raphael Ho scritto "tipicamente" perché con i processori che ho incontrato, la cache in sé non ha alcuna conoscenza di thread, processi, contesti, ecc. Reagisce solo agli accessi alla memoria. Se la cache dei dati viene svuotata e la cache delle istruzioni non è valida su un cambio di contesto, è il sistema operativo che attiva questa azione non la cache. Se si installa un sistema operativo diverso, questo comportamento potrebbe cambiare.
uli

@Gilles Per una volta ho provato a dare una risposta breve e ho deciso di non scrivere sulla memoria virtuale, perché questo coinvolge immediatamente il sistema operativo. E c'è anche il calendario da considerare. "Nulla cambia" potrebbe essere una risposta per il tempo tra il cambio di contesto e il successivo accesso alla memoria, poiché il contenuto della cache potrebbe essere invalidato ma non modificato affatto.
uli
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.