2013-09-26 22 views
14

Quale indirizzamento viene utilizzato nei processori x86/x86_64 per la memorizzazione nella cache in L1, L2 e L3 (LLC) - fisico o virtuale (utilizzando PT/PTE e TLB) e in qualche modo influisce su PAT(page attribute table)?L'indirizzamento fisico o virtuale viene utilizzato nei processori x86/x86_64 per la memorizzazione nella cache in L1, L2 e L3?

In questo caso c'è differenza tra i driver (spazio kernel) e le applicazioni (spazio utente)?

+0

Non è possibile indirizzare la cache. Puoi solo indirizzare la memoria. La cache è gestita privatamente dalla CPU. –

+1

@Kerrek SB Sì, lo so, ma CPU-cache utilizza TLB e tutti i sovraccarichi dell'indirizzamento virtuale o no? – Alex

risposta

28

La risposta alla tua domanda è - dipende. Questa è strettamente una decisione progettuale della CPU, che bilancia rispetto al compromesso tra prestazioni e complessità.

Prendete ad esempio i recenti processori Intel Core: sono taggati fisicamente e praticamente indicizzati (almeno secondo lo http://www.realworldtech.com/sandy-bridge/7/). Ciò significa che le cache possono solo completare le ricerche in puro spazio di indirizzamento fisico, al fine di determinare se la linea è presente o meno. Tuttavia, poiché L1 è 32k, associativo a 8 vie, significa che utilizza 64 set, quindi è necessario solo i bit di indirizzo da 6 a 11 per trovare il set corretto. Come accade, gli indirizzi virtuali e fisici sono gli stessi in questo intervallo, quindi è possibile cercare il DTLB in parallelo con la lettura di un set di cache - un trucco noto (vedere - http://en.wikipedia.org/wiki/CPU_cache per una buona spiegazione).

In teoria si può costruire una cache con tag virtualmente + virtualy tagged, che rimuoverà il requisito di passare attraverso la traduzione degli indirizzi (ricerca TLB, e anche le pagine camminano in caso di mancanze del TLB). Tuttavia, ciò causerebbe numerosi problemi, in particolare con l'aliasing della memoria, un caso in cui due indirizzi virtuali si associano a quello stesso fisico.

Dire core1 ha virtual addr A cache in una cache completamente virtuale (si associa a addr C, ma non abbiamo ancora eseguito questo controllo). core2 scrive nell'additivo virtuale B che mappa allo stesso indirizzo fisico C - questo significa che abbiamo bisogno di un meccanismo (di solito un "ficcanaso", termine coniato da Jim Goodman) che va e invalida quella linea in core1, gestendo la fusione dei dati e la gestione della coerenza se necessario. Tuttavia, core1 non può rispondere a tale ficcanaso poiché non conosce l'addr virtuale B e non memorizza l'addr C fisico nella cache virtuale. In questo modo puoi vedere che abbiamo un problema, sebbene questo sia per lo più rilevante per i sistemi x86 rigorosi, altre architetture potrebbero essere più lassiste e consentire una gestione più semplice di tali cache.

Per quanto riguarda le altre domande: non è possibile stabilire una vera connessione con PAT, la cache è già stata progettata e non può essere modificata per diversi tipi di memoria. La stessa risposta per l'altra domanda: l'HW è per lo più al di sotto della distinzione tra modalità utente/kernel (eccetto per i meccanismi che fornisce il controllo di sicurezza, soprattutto i vari anelli).

+1

Grazie mille! E secondo te, c'è qualche vantaggio dalla conoscenza del meccanismo su x86 e se l'io come sviluppatore sapendo questo, posso in qualche modo ottimizzare le prestazioni del mio programma? – Alex

+2

Assolutamente, uno sviluppatore SW che non conosce l'HW in cui gira farebbe un lavoro scarso nell'ottimizzarlo (se necessario), o nel debugarlo (quando necessario per :). Il tipo di indirizzo di mappatura della cache è un po 'basso, anzi, sebbene apra un tratteggio ad alcune importanti ottimizzazioni come l'intrigo di prefetch SW e la progettazione di cache-aware). Vedi questo ottimo post per gli esempi: http://stackoverflow.com/questions/16699247/what-is-cache-friendly-code. C'è anche la questione dell'esecuzione fuori ordine che potrebbe fornire alcuni suggerimenti e, naturalmente, la varietà di ottimizzazioni del compilatore (non HW, ma anche importante) – Leeor

+0

Voglio dire - approfittare della consapevolezza che in x86: "sono taggato fisicamente e praticamente indicizzato " – Alex