[IDF08] Intel Nehalem in-depth preview

Inhoudsopgave
  1. 1. Inleiding
  2. 2. Blokdiagram
  3. 3. Slimmer omgaan met instructies
  4. 4. Branch prediction en execution units
  5. 5. Terugkeer van HyperThreading
  6. 6. Geheugenmanagement
  7. 7. Caching
  8. 8. QuickPath
  9. 9. Geïntegreerde geheugencontroller
  10. 10. Virtualisatie
  11. 11. Power controller
  12. 12. Turbo modus
  13. 13. Conclusie

Caching

De cache architectuur van Nehalem is zoals al besproken ook compleet anders dan bij de Core architectuur van de bestaande Core 2 processors. Bij de bestaande CPU's heeft iedere core eigen L1 data- en instructiecache en daarnaast delen twee cores een stuk L2-cache. Bij Nehalem is ook die L2-cache voor iedere core afzonderlijk. Er is echter een derde, gedeelde cachelaag. De belangrijkste reden voor deze aanpassing is dat Nehalem native quadcore is; ofwel vier kernen in één chip. Als vier cores toegang zouden hebben tot de L2-cache, zou de toegangstijd daartoe in veel gevallen veel te lang worden. 

De Nehalem cores hebben elk 256 kB L2-cache die zeer snel te benaderen is. In de meeste gevallen bedraagt de toegangstijd zo'n 10 klokslagen. 

De L3-cache wordt gedeeld door alle cores. Deze is vanzelfsprekend langzamer dan de L2, maar nog altijd relatief snel. Wanneer een core data uit L3 wil halen, kost dat in de regel zo'n 35 a 36 klokslagen. De L3-cache is een 16-way ontwerp, wat betekent dat bij een quad-core processor iedere kern vier parallelle ingangen tot het cachegeheugen heeft.

De L3-cache is zogenaamde inclusive, want betekent dat alle data die in de L1 en L2 cache staat, ook verplicht in de L3-cache aanwezig moet zijn. Dat lijkt op het eerste gezicht onlogisch, aangezien je daardoor in feite onder de streep minder cache capaciteit hebt. Toch is dat juist erg slim, aangezien je op die manier direct een snoop filter kado krijgt.

De werking van een snoop filter is gelukkig niet lastig om te begrijpen. De basis zit hem in de functie van cache geheugen; dit doet immers dienst als een buffer voor het relatief veel tragere RAM-geheugen in de PC. Wanneer een core data wil verschrijven naar het geheugen, zal hij dit in eerste instantie naar zijn eigen L1- of L2-cachegeheugen doen. Daarna kan de core weer verder met nieuwe berekeningen, waarna de data op een later tijdstip daadwerkelijk naar het geheugen wordt overgebracht. Andersom werkt het ook; wanneer een core data uit het geheugen nodig heeft, wordt er getracht om deze vooraf al in het snelle cache te hebben staan.

Zodra een PC echter meerdere processors of meerdere cores heeft, ontstaat er een potentieel probleem. Stel dat core 1 een stuk data heeft verwerkt en dat wil wegschrijven naar geheugenruimte X. De nieuwe data staat dan op dat moment in z'n eigen cache, maar is nog niet doorgevoerd naar het RAM-geheugen. Wanneer de core juist op dat moment de geheugenruimte X uitleest, krijgt hij verouderde data binnen, want kan leiden tot een programma crash. Om dat probleem te verkomen zijn snoop filters bedacht. Zo'n snoop filter bekijkt wanneer er data uit het geheugen wordt opgevraagd, stiekem (snoopen dus in het Engels) of deze data toevallig in de cache van andere cores is aangepast. Zo ja, wordt data daar vandaan gehaald.

Aangezien de data van alle L1- en L2-caches van de afzonderlijke cores verplicht wordt gekopieerd naar de gedeelde L3-cache, hoeven de snoop filters nooit daadwerkelijk de cache van de andere cores in, waardoor deze niet vertraagd kunnen worden. Om de werking verder te verbeteren hebben alle cache-lijnen in de gedeelde L3-cache voor iedere core één extra bit aanwezig. Hiermee wordt aangegeven bij welke cores de betreffende data wel en niet in de L1- of L2-cache zit. Snoop filters weten op die manier direct of ze zich wel of geen zorgen moeten maken.

Advertentie
0