Secondo quanto ho letto da due diverse fonti, la colorazione della cache è (era?) necessaria per:
-
Contrasta il problema dellaliasing: Impedisci a due diversi indirizzi virtuali con lo stesso indirizzo fisico di mappare su set di cache diversi . (Secondo una CS Stack Exchange Answer )
-
Sfrutta la proprietà di località spaziale della memoria virtuale : garantendo che due blocchi adiacenti di memoria virtuale (non necessariamente adiacenti nella memoria fisica), non vengano mappati allo stesso indice di cache. (Secondo Wikipedia )
Mi sembrano definizioni fondamentalmente diverse e senza comprendere il motivazione per la colorazione della cache, non riesco a capire il meccanismo per selezionare il numero di colori richiesti. Sono davvero la stessa cosa?
Se la località spaziale della memoria virtuale è la motivazione principale, è la colorazione della cache è davvero richiesta per le cache VIPT, dove lindice della cache è derivato dalla memoria virtuale per cominciare? O la colorazione della cache viene semplicemente utilizzata nelle cache VIPT per aggirare laliasing?
Risposta
Sia evitare gli alias che evitare conflitti di cache eccessivi sono validi motivi per utilizzare la colorazione della pagina. Richiedere la colorazione della pagina per evitare alias è impopolare perché pone un vincolo obbligatorio sullallocazione della pagina. i processori generali e moderni non incorporati non richiedono la colorazione della pagina per evitare lalias.
Evitare problemi di aliasing nellhardware i n aumenta la complessità dellhardware, quindi i processori precedenti (e forse alcuni processori embedded più recenti) scelsero di caricare il software. Lhardware può evitare problemi di aliasing in una cache con più bit di indice + offset che bit nelloffset di pagina (ad esempio):
- controllando i set alternativi in caso di errore nella cache (come fatto da AMD “s Athlon; quando è stato rilevato un alias, il blocco è stato spostato nellindice virtuale corrente)
- inclusi i bit dellindirizzo virtuale utilizzati per lindicizzazione di L1 in un (tag) incluso L2 (in caso di mancato L1 e L2 hit, i bit dellindirizzo virtuale corrispondono ai bit corrispondenti per la richiesta, non è necessaria alcuna azione; se i bit non corrispondono, è noto lappropriato set da sondare [se il blocco è anche in L1 potrebbe anche essere memorizzato nei tag L2 per ridurre la coerenza sovraccarico, quindi è possibile evitare alcune sonde])
- utilizzando set prediction per indovinare i bit di indirizzo fisico aggiuntivi utilizzati per lindicizzazione (una previsione errata verrebbe scoperta dopo laccesso TLB e corretta)
- utilizzando traduzione inversa (da fisica a virtuale) in una cache non riesce a trovare possibili alias (penso che unimplementazione PA-RISC abbia utilizzato la traduzione inversa attivato per coerenza )
Usare la colorazione delle pagine per ridurre i conflitti (per le cache con un semplice modulo una potenza di due indicizzazione) è meno impopolare perché la colorazione della pagina non è richiesta per correttezza. Se un determinato colore diventa scarso, una pagina può essere colorata in modo errato con solo una possibile riduzione delle prestazioni. Questa logica per colorare le pagine significa anche che il numero di bit colorati è meno limitato. Lideale (meno pratico) potrebbe essere quello di abbinare tutti i bit dellindice fisico per la cache di ultimo livello con i bit degli indirizzi virtuali corrispondenti, ma anche colorare solo quattro bit può ridurre sostanzialmente i problemi di conflitto.
Potrebbe valere la pena notare che la colorazione per evitare gli alias non deve necessariamente far corrispondere i bit degli indirizzi virtuali con i bit degli indirizzi fisici. Finché tutti i potenziali alias condividono gli stessi bit di indirizzo virtuale usati per lindicizzazione, si evitano problemi di alias. Tuttavia, la corrispondenza dei bit degli indirizzi fisici e virtuali può essere conveniente (e fornire un conflitto prevedibile nei livelli di cache indirizzati fisicamente).