Le tabelle delle pagine sono memorizzate nella cache?

Su un microprocessore con gestione TLB hardware (diciamo Intel x86-64) se si verifica un errore TLB e il processore percorre la tabella delle pagine, questi accessi alla memoria (off-chip) passano attraverso la gerarchia della cache (L1, L2, ecc. )?

Sì, per quanto posso dire, sui processori Intel x86-64, quando si verifica un errore TLB e il processore percorre la tabella delle pagine, gli accessi alla memoria off-chip passano attraverso la gerarchia della cache.

Sono ancora un po 'confuso su alcuni dettagli e spero che qualche altra risposta li riempia: non c'è un manuale Intel o AMD che descriva la camminata della pagina in dettagli lancinanti? La mia comprensione è che:

• L'indirizzo virtuale in alcuni registri di indirizzi viene prima trasferito in un TLB veloce per essere convertito in un indirizzo fisico: l'indirizzo nel PC viene trasferito a L1 ITLB, l'indirizzo in qualsiasi altro registro viene trasferito a L1 DTLB .
• Se manca quella prima ricerca, viene tentato un altro livello di TLB più lento e più grande. (Questo TLB L2 è anche suddiviso in ITLB e DTLB o è una cache TLB unificata? Esistono ulteriori livelli TLB: L3? L4?)
• Se la ricerca TLB fallisce completamente e il walker VHPT x86 e x86-64 è disabilitato, la CPU segnala un errore mancante TLB, che viene intercettato dal kernel del sistema operativo. La mia comprensione è che praticamente tutte le CPU non x86 fanno la stessa cosa: gestiscono le mancanze TLB interamente nel software. Se abilitati, i processori x86 e x86-64 hanno un camminatore da tavolo VHPT assistito dall'hardware che gestisce i passaggi successivi. (I chip x86 e x86-64 hanno un bit che disabilita completamente VHPT o ci sono molti bit che possono abilitare VHPT per alcuni intervalli di indirizzi e disabilitare VHPT per altri intervalli di indirizzi? Dove si trovano quei bit?)
• se la ricerca TLB fallisce completamente, l'indirizzo virtuale originale (probabilmente in modalità utente) V1 viene convertito in V2, l'indirizzo virtuale della voce della tabella delle pagine PTE che contiene il numero di pagina fisica per V1.
• Poiché V2 è di nuovo un indirizzo virtuale, la CPU passa attraverso la normale traduzione degli indirizzi da virtuale a fisico, tranne che salta L1 e passa direttamente a L2.
• L'hardware cerca l'indirizzo virtuale V2 nel TLB in parallelo con il recupero di quel PTE dalla cache L2 (praticamente indicizzata).
• Poiché V2 non è l'indirizzo di un'istruzione, non passa attraverso la cache dell'istruzione L1; e poiché V2 non è l'indirizzo dei normali dati utente, non passa attraverso la cache di dati L1. V2 viene inizialmente immesso nella cache unificata L2 (un'istruzione unificata + dati + cache PTE). Vedi "esempio di gerarchia di cache" .
• Se la cache L2 (o L3 o qualsiasi altra cache virtualmente indicizzata) contiene il PTE, il VHPT recupera il PTE dalla memoria cache e installa il PTE per V1 nel TLB e l'indirizzo fisico in quel PTE viene utilizzato per tradurre il indirizzo virtuale originale V1 nell'indirizzo RAM fisico, eventualmente recuperando quei dati o istruzioni interamente nell'hardware senza alcuna assistenza dal sistema operativo.
• Se tutti i livelli della cache indicizzata virtualmente falliscono, ma questa seconda ricerca TLB riesce per V2, allora il VHPT recupera la PTE dalla cache indicizzata fisicamente o dalla memoria principale, installa la PTE per V1 nella TLB e l'indirizzo fisico in quella PTE viene utilizzato per tradurre l'indirizzo virtuale originale V1 nell'indirizzo RAM fisico, recuperando infine quei dati o istruzioni interamente nell'hardware senza alcuna assistenza dal sistema operativo.
• Se questa seconda ricerca TLB fallisce, l'hardware VHPT walker rinuncia a un VHPT TRANSLATION FAULT.
• Quando si verifica un GUASTO DI TRADUZIONE VHPT, la CPU esegue il trap al sistema operativo. Il sistema operativo deve capire cosa è andato storto e sistemare le cose:
• (a) forse la pagina contenente V2 è attualmente scambiata su disco, quindi il sistema operativo la legge nella RAM e riavvia l'istruzione non riuscita, oppure
• (b) forse un programma difettoso sta cercando di leggere o scrivere o eseguire un percorso non valido e il sistema operativo termina il processo, oppure
• (c) una varietà di altri trucchi che gli scrittori del sistema operativo fanno per utilizzare questo meccanismo per intercettare vari tipi di accesso: caricare la pagina contenente V1 che può essere scambiata su disco; varie trappole utilizzate per il debug di nuovi programmi; simulare "W ^ X" su CPU che non lo supportano direttamente; supportare il copy-on-write; eccetera.

Lo schema a pagina 2 di Thomas W. Barr, Alan L. Cox, Scott Rixner. "Translation Caching: Skip, Don't Walk (la tabella delle pagine)" che traccia una linea tra "Voci archiviate dalla cache MMU" e "Voci archiviate dalla cache di dati L2". (Questo può essere un documento utile per le persone che progettano nuove CPU , che è totalmente in tema di "progettazione elettronica").

Stephane Eranian e David Mosberger. "Memoria virtuale nel kernel Linux IA-64" e Ulrich Drepper. "Ciò che ogni programmatore dovrebbe sapere sulla memoria" (Questo può essere un documento utile per le persone che scrivono sistemi operativi che si occupano della tabella delle pagine IA-64, che è un po 'fuori tema per ED - forse Stack Overflow con il "operativo- system " o il tag " osdev " o il wiki OSDev.org sarebbe un posto migliore per quell'argomento).

Tabella A-10 a pagina 533 di Intel. "Manuale dello sviluppatore del software per architetture Intel® 64 e IA-32" "PAGE_WALKS.CYCLES ... può suggerire se la maggior parte delle pagine sono soddisfatte dalle cache o causano un errore nella cache L2."

Tendo a concordare sul fatto che questo appartiene a uno stackexchange di architettura di computer, non a uno scambio di stack di elettronica, ma poiché questo è qui:

@davidcary è corretto.

Un po 'di storia:

I passi delle tabelle delle pagine Intel x86 NON sono stati memorizzati nella cache fino a P5, alias Pentium. Più precisamente, gli accessi alla memoria della tabella delle pagine non sono stati memorizzati nella cache, ignorando la cache. Poiché la maggior parte delle macchine fino a quel momento erano in scrittura, hanno ricevuto valori coerenti con la cache. Ma non curvarono le cache.

P6, noto anche come Pentium Pro e AFAIK, a tutte le successive passeggiate nella tabella delle pagine dei processori era consentito accedere alla cache e utilizzare un valore estratto dalla cache. Pertanto, hanno lavorato con cache di riscrittura. (È possibile ovviamente posizionare le tabelle delle pagine in una memoria non memorizzabile, definita, ad esempio, dagli MTRR. Ma si tratta di una grande perdita di prestazioni, sebbene possa essere utile per il debug dei sistemi operativi.)

A proposito, questo "accesso alla memoria della tabella delle pagine può accedere alle cache dei dati" è separato da "le voci della tabella delle pagine possono essere memorizzate (memorizzate nella cache) in un buffer TLB Ttranslation Lookaside)". Su alcuni computer il TLB è chiamato "cache di traduzione".

Un altro problema correlato è che i nodi interni delle tabelle delle pagine possono essere memorizzati nella cache in strutture di dati ancora più simili a TLB, ad esempio la cache PDE.

Una differenza fondamentale: la cache di dati è coerente e curvata. Ma le cache TLB e PDE non sono curvate, ovvero non sono coerenti. La linea di fondo è che, poiché le tabelle delle pagine possono essere memorizzate nella cache in TLB e cache PDE non coerenti, ecc., Il software deve esplicitamente svuotare sia le singole voci sia i gruppi di massa (come l'intero TLB), quando le voci della tabella delle pagine che potrebbero essere state tali vengono memorizzati nella cache. Almeno se modificato in modo "pericoloso", passando da RW-> R-> I o cambiando indirizzo.

Penso che sia corretto affermare che ogni volta che viene aggiunto un nuovo tipo di cache non coerente come TLB, alcuni sistemi operativi si sono rotti, poiché aveva implicazioni implicite che ciò non avveniva.