Qual è la differenza tra cache fisica e virtuale?


11

Ho difficoltà a capire che cos'è effettivamente la cache virtuale. Capisco la memoria virtuale.

Se la CPU vuole accedere alla memoria, per quanto ho capito, invia un indirizzo virtuale alla MMU che, usando le tabelle delle pagine, calcola l'indirizzo di memoria fisica.

Inoltre, la CPU invia un indirizzo diverso (solo la fine dell'indirizzo virtuale), che consiste in un set n. un tag e un offset, alla cache che poi funziona se risiede nella cache.

In cosa differisce la cache virtuale da questa?

inserisci qui la descrizione dell'immagine


2
Intendi una cache virtualmente indirizzata (praticamente indicizzata / virtualmente etichettata)?
Paul A. Clayton,

Fondamentalmente intendo qual è la differenza tra un indirizzo di cache virtuale e un indirizzo di cache fisico? (Avevo l'impressione che un indirizzo cache fisico sia nel formato (setno. (Indice), tag (n.
Riga

Vedi il mio documento di indagine del 2017 su TLB , in cui discuto e confronto quattro tipi di opzioni di indirizzamento della cache (PIPT, VIPT, VIVT, PIVT) con le cifre. Questo risponderà alla tua domanda. La cache VIVT viene generalmente definita cache virtuale.
user984260

Risposte:


20

Esistono quattro modi per indirizzare una cache a seconda che vengano utilizzati bit di indirizzo fisici o virtuali per l'indicizzazione e / o per la codifica.

Poiché l'indicizzazione della cache è il tempo più critico (poiché tutti i modi in un set possono essere letti in parallelo e il modo appropriato selezionato in base a un confronto di tag), le cache sono in genere indicizzate con l'indirizzo virtuale, consentendo l'indicizzazione per iniziare prima dell'indirizzo la traduzione è completata. Tuttavia, se per l'indicizzazione vengono utilizzati solo bit all'interno dell'offset della pagina (ad esempio, con ciascuna via non più grande della dimensione della pagina e del semplice modulo della dimensione della via per l'indicizzazione 1 ), tale indicizzazione utilizza effettivamente l'indirizzo fisico. Non è insolito che l'associatività L1 venga aumentata principalmente per consentire a una cache più grande di essere indicizzata dall'indirizzo fisico.

Sebbene l'indicizzazione basata sull'indirizzo fisico sia possibile con modalità maggiori della dimensione della pagina (ad esempio, prevedendo i bit più significativi o un meccanismo di traduzione veloce che fornisce quei bit utilizzando il ritardo dell'indicizzazione con i bit dell'indirizzo fisico noti per nascondere la latenza della traduzione), non è comunemente fatto.

L'uso degli indirizzi virtuali per la codifica consente di determinare un hit della cache prima che sia stata eseguita la traduzione. Le autorizzazioni devono ancora essere verificate prima che sia possibile eseguire il commit dell'accesso, ma per i carichi i dati possono essere inoltrati alle unità di esecuzione e il calcolo utilizzando i dati iniziati e per gli archivi i dati possono essere inviati a un buffer per consentire un impegno di stato ritardato. Un'eccezione di autorizzazione eliminerebbe la pipeline, quindi questo non aggiunge complessità di progettazione.

(I vhint utilizzati dalla cache di dati Pentium 4 hanno fornito questo vantaggio di latenza utilizzando un sottoinsieme dei bit di indirizzo virtuale disponibili in anticipo per selezionare in modo speculativo il modo.)

(Ai tempi delle MMU esterne opzionali, i tag di indirizzo virtuale potevano essere particolarmente interessanti nel spingere la traduzione quasi completamente al di fuori del design della cache.)

Sebbene le cache virtualmente indicizzate e taggate possano avere significativi vantaggi di latenza, introducono anche il potenziale di aliasing in cui lo stesso indirizzo virtuale viene mappato a indirizzi fisici diversi (omonimi) o lo stesso indirizzo fisico mappa mappe a indirizzi virtuali diversi (sinonimi). L'indicizzazione e la codifica con indirizzi fisici evitano l'aliasing.

Il problema omonimo viene risolto in modo relativamente semplice utilizzando gli identificatori dello spazio degli indirizzi (ASID). (Anche lo svuotamento della cache quando si modificano gli spazi degli indirizzi non garantirà omonimi, ma è relativamente costoso. Sarebbe necessario almeno lo svuotamento parziale quando un ASID viene riutilizzato per uno spazio di indirizzi diverso, ma un ASID a 8 bit può evitare i flush sulla maggior parte degli indirizzi lo spazio cambia). In genere gli ASID vengono gestiti dal sistema operativo, ma alcuni sistemi forniscono controlli hardware per il riutilizzo dell'ASID in base all'indirizzo di base della tabella delle pagine.

Il problema dei sinonimi è più difficile da risolvere. In caso di mancata memorizzazione nella cache, è necessario verificare gli indirizzi fisici di eventuali alias per determinare se un alias è presente nella cache. Se l'aliasing viene evitato nell'indicizzazione, indicizzando con l'indirizzo fisico o dal sistema operativo garantendo che gli alias abbiano gli stessi bit nell'indice (colorazione della pagina), allora è necessario sondare solo un set. Spostando qualsiasi sinonimo rilevato sull'insieme indicato dall'indirizzo virtuale utilizzato più di recente, l'alias viene evitato in futuro (fino a quando non si verifica una diversa mappatura dello stesso indirizzo fisico).

In una cache con tag virtualmente mappata diretta senza aliasing dell'indice, è possibile un'ulteriore semplificazione. Poiché il potenziale sinonimo entrerà in conflitto con la richiesta e verrà sfrattato, è possibile eseguire qualsiasi riscrittura necessaria di una linea sporca prima che venga gestita la cache miss (quindi un sinonimo sarebbe in memoria o una cache di livello superiore indirizzata fisicamente) o indirizzata fisicamente il buffer di writeback può essere sondato prima dell'installazione della riga della cache recuperata dalla memoria (o cache di livello superiore). Non è necessario controllare un alias non modificato poiché il contenuto della memoria sarà lo stesso di quello nella cache, facendo semplicemente una gestione delle miss non necessaria. Ciò evita la necessità di ulteriori tag fisici per l'intera cache e consente una traduzione relativamente lenta.

Se non è possibile evitare l'aliasing nell'indice, anche una cache con tag fisico dovrà controllare gli altri set che potrebbero contenere alias. (Per un bit di indice non fisico, un secondo sondaggio della cache nel singolo set alternativo potrebbe essere accettabile. Ciò sarebbe simile alla pseudo-associatività.)

Per una cache praticamente taggata, è possibile fornire un set aggiuntivo di tag di indirizzi fisici. Questi tag sarebbero accessibili solo in caso di errore e possono essere utilizzati per coerenza della cache di I / O e multiprocessore. (Poiché le mancate richieste e la coerenza sono relativamente rare, questa condivisione non è in genere problematica.)

Athlon di AMD, che utilizzava il tagging fisico con l'indicizzazione virtuale, ha fornito un set separato di tag per sonde di coerenza e rilevamento di alias. Poiché per l'indicizzazione vengono utilizzati tre bit di indirizzo solo virtuali, è stato necessario sondare sette insiemi alternativi per possibili alias in errore. Poiché ciò potrebbe essere fatto in attesa di una risposta dalla cache L2, ciò non ha aggiunto latenza e il set aggiuntivo di tag potrebbe essere utilizzato anche per richieste di coerenza che erano più frequenti data l'esclusività della cache L2.

Per una cache L1 praticamente indicizzata di grandi dimensioni, un'alternativa al sondaggio di molti set aggiuntivi sarebbe quella di fornire una cache di traduzione da fisica a virtuale. In caso di errore (o sonda di coerenza) l'indirizzo fisico verrebbe tradotto nell'indirizzo virtuale che potrebbe essere utilizzato nella cache. Poiché fornire una voce della cache di traduzione per ciascuna riga della cache non sarebbe pratico, sarebbe necessario un mezzo per invalidare le righe della cache quando viene sfrattata una traduzione.

Se si garantisce che l'aliasing (almeno degli indirizzi scrivibili) non si verifica, ad es. In un tipico sistema operativo dello spazio di indirizzamento singolo, l'unico svantaggio di una cache praticamente indirizzata è l'overhead del tag aggiuntivo rispetto al fatto che gli indirizzi virtuali in tali sistemi sono più grande di indirizzi fisici. L'hardware progettato per un singolo spazio degli indirizzi OS potrebbe utilizzare un buffer lookaside di autorizzazione anziché un buffer lookaside di traduzione, ritardando la traduzione fino a un errore di cache di ultimo livello.


1 L'associatività distorta indicizza diversi modi della cache con hash diversi in base a più bit del necessario per l'indicizzazione del modulo con le stesse modalità di dimensione. Questo è utile per ridurre i conflitti. Ciò può introdurre problemi di alias che non sarebbero presenti in una cache indicizzata per modulo della stessa dimensione e associatività.


"Non è insolito che l'associatività L1 venga aumentata principalmente per consentire a una cache più grande di essere indicizzata dall'indirizzo fisico." Volevi dire virtuale lì? Come in, per mantenere il numero di bit di selezione dei set abbastanza basso da rimanere interamente all'interno di una pagina (e quindi non necessita di traduzione), in modo che la cache possa continuare a essere indicizzata fisicamente con tag fisici per una latenza inferiore. O stavi chiamando quei bit sotto l'offset della pagina "indirizzi fisici"?
Peter Cordes,

1
@PeterCordes Stavo chiamando l'offset all'interno di una parte della pagina dell'indirizzo fisico (per quei bit virtuali === fisico). Se si enfatizza la latenza, si potrebbe tendere a chiamarlo virtualmente indicizzato; se si enfatizza la mancanza di problemi di aliasing, si potrebbe tendere a chiamarlo fisicamente indicizzato.
Paul A. Clayton,

Grazie. Sei stato avvisato quando ti ho taggato in un'altra discussione su stackoverflow.com/questions/33974193/… ? Speravo in una risposta esperta sul fatto che le cache L2 / L3 siano tipicamente indicizzate fisicamente, quindi possono essere grandi senza bisogno di associatività massiccia. (Suppongo di sì, perché non vengono controllati fino a quando non manca L1, cosa che accade dopo TLB, quindi l'indirizzo fisico è disponibile). Ci sono anche un paio di altre cose sconcertanti emerse in quella discussione.
Peter Cordes,
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.