En överblick på cachedesignen i Intels mikroarkitektur Nehalem Tillsammans med utvecklingen av cacheminnen förekommer det även ett flertal problem med att styra och organisera data. Trots att det sker stora framsteg inom hårdvaruutvecklingen för datorminnen kvarstår de logiska problemen med att designa och strukturera cache minnen för bästa prestanda i en processor. I denna rapport ges en överblick på mikroarkitekturen Nehalems cachedesign i syfte till att ge läsaren en överskådlig uppfattning på vad som kan förekomma i cache minnen, vilka problem en cachedesigner måste ha överseende med och möjliga lösningar till problemen. Introduktion Innan detaljerna kring cachedesignen diskuteras ges en kort introduktion på problemen kring cache designen och viktiga faktorer inom cache design. Cachedesign har en kritisk betydelse för en processors prestanda. Trots att cacheminnen ursprungligen hade en mer klar roll har det uppstått det fler problem i takt med framsteg inom mikroprocessorteknik. Flera av dessa problem ankrar sig i hårdvarubegränsningar men även suboptimal design av systemarkitektur. Därför är det viktigt att med senaste teknik kunna förse en processor med bästa möjliga designlösningar. Det finns flera parametrar som påverkar cachedesignen. Dels måste cacheminnet vara högeffektiv i den meningen att cacheminnet måste vara pålitlig. Detta inkluderar låg accesstid, låg strafftid vid miss, hög hit rate och minneskonsistens. Men på senare tid har fler problem uppstått i samband med multicore processorer och medvetenhet inom energiförbrukning. Detta ökar kraven på cachedesign och lösningarna blir även med komplexa. Bortsett från att allmänt förbättra arkitekturen ville Intel även göra Nehalem mer modulär och mer skalbart, vilket krävde en mindre omvälvning i cachestrukturen. Delämnen som kommer att beröras är följande: En översikt av cachearkitekturen i Nehalem MESIF protokollet och koherens Intels implementation av TLB, translation lookaside buffer, i Nehalem Intels implementation av cache inclusion. Tidigare implementation av minnesarkitektur. Problem med tidigare cachearkitekturer Innan Intel lanserade Nehalen led föregångaren Core av några fundamentala problem. I detta stycke adresseras några av de problemen gällande Cores cachedesign.
Core led av brister inom dataöverföring. De tidigare Core-arkitekturerna bestod av, beroende på prestandaklass, en eller fler singel eller dubbelkärniga mikrochip. Detta satte en oerhörd press på processorns buss, vilket till slut blev en flaskhals för systemet. Detta gäller för bussen mellan RAMminne och processor, men även mellan kärnor. Med en överbelastad dataöverföringsbuss lämnade detta lite utrymme för fler kärnor i arkitekturen (Rolf, 2009:1). Detta var ett stort problem innan, men idag är det mer en fråga om skalbarhet. En möjlig lösning på detta är att försöka göra processorn så modulär som möjligt, vilket betyder att varje mikrochip ska kunna kopplas ihop utan avsevärt försämrad prestanda (Awashti et al, 2011:57). I äldre processorer var minneskontrollern en ordentlig flaskhals eftersom den var placerad off-chip på moderkortets nordbrygga, vilket betyder att processorn inte kommunicerar direkt med RAMminnet utan kommunicerade i första hand med minneskontrollern, som i sin tur kommunicerade med RAM-minnet. Detta orsakade en högre latens än nödvändigt (Rolf, 2009:3). Nehalems systemarkitektur Intel ville göra arkitekturen mer modulär och mer skalbar. Detta krävde fundamentala förändringar, men lösningen är simpel i design. Nedanför förklaras översiktligt systemarkitekturen i Nehalem. I tidigare Core modeller satt två kärnor i ett mikrochip, där varje core hade en L1 Cache men delade på en L2 Cache. Detta blev minnesmässigt inte lika komplett då alla enkelkärniga processorer oftast hade en egen L1 och L2 cache per kärna. Nehalem löste detta genom att introducera en tredje delad cache, såkallad L3 Cache. L2 cache blev istället en självständig cache tillsammans med L1 för var kärna. Front Side Bus (FSB), databussen mellan processorn och nordbryggan, är inte längre aktuell i Nehalem och har ersatts med Quick Path Interconnect (QPI), som är en point-to-point länk mellan mikrochipsen (Molka et al 2009:261). Figur 1 En åttakärnig Nehalem processor (2009) I Core-arkitekturen var det ett problem med att minneskontrollen befann sig i moderkortets nordbrygga. Intel löste detta i Nehalemarkitekturen genom att införa en integrerad minneskontroller (eng. integrated memory controller, IMC) (Molka et al 2009:261). IMC:n är utrustad med trippel kanaler för dataöverföring, vilket ska enligt teori ska minska tiden för minnesaccess betydligt. Att integrera minneskontrollern i processorchippet medför att processorn blir mindre beroende av moderkortet, vilket gjorde processorn mer modulärt (Rolf, 2009:3).
Cachespecifikationer I den här delen presenteras de mer specifika cachespecifikationerna. Som tidigare förklarats har Intel gått från en minneshierarki med två nivåer till en minneshierarki med tre nivåer. L1 cachen är 32kB i storlek och använder sig av writeback policy. Cacheline storleken är på 64 bytes och utnyttjar 8-way set associative. L2 cache, som Intel själva kallar för MLC, är 256 kb stor. Den har likväl 64 bytes cachelinjestorlek, använder sig av 8-way set associative och writeback policy. MLC:n innehåller både instruktioner och data (Dixon et al 2010:17). Nehalems processorer använder sig utav inclusive 8 MB L3 cache. Vad detta innebär är att det data som finns i övre minneshierarkin måste även finnas i nivån under. Med andra ord måste L3 cachen i Nehalem innehålla data från L2 och L1. I L3 finns en så kallad core valid bit, som visar om sökt cachelinje finns i en kärnas cacheminne. Den cachedesignen skiljer sig från non-inclusive eller exclusive cachedesign, som betraktar minnen i hierarkin som självständiga. För att vara helt säker på om en cachelinje finns i en specifik kärna måste därför alla cacheminnen i minneshierarkin undersökas i ett non-inclusive cacheminne (Jaleel et al 2010:1). Fördelen med inclusive cachedesign är dess simpla design. Detta har stor betydelse då växande multiprocessorteknologi blir frågan kring minneshantering mer och mer komplex. Med en simpel design tillkommer även hinder i flexibilitet, vilket orsakar sämre prestanda. Grunden till detta ligger bland annat i att cachelinjer måste överskridas för att tillgodose att designen förblir inclusive (Jaleel et al 2010:1). Cache koherens och MESIF protokollet Med fler kärnor och fler cacheminnen blir det betydligt svårare att tillfredsställa minneskonsistensen. Intel löste detta i Nehalem genom att bland annat introducera MESIF protokollet, som är baserad på MESI protokollet. Följande text förklarar kort definitionen av cache koherens och även MESIF protokollet. Att en cache är koherent innebär i stora drag att cacheminnen för alla kärnor i en processor är tidsenligt konsekventa med varandra och minnet. Exempelvis kan en situation ske där en minnesplats läses av en processor under tiden en annan processor skriver till samma minnesplats, vilket kommer att medföra att en processor har tillgång till felaktig data. Ett viktigt koncept som löser detta problem är write serialization, som innebär att processorminnet uppdateras i samma ordning som den skrivs i (Patterson 2014:467) Det finns två huvudsakliga egenskaper ett cachesystem måste ha för att kunna bli koherent, migration och kopiering (eng. replication). Migration innebär att en cache ska kunna flytta på data inom systemet för användning. Som namnet antyder är kopiering snarlik, med skillnaden att data kopieras istället. Det finns flertal sätt att implementera detta, för Nehalem-arkitekturen är det MESIF protokollet som är aktuellt (Patterson 2014:466 468). Innan Intel introducerade MESIF-protokollet tillsammans med Nehalem var MESI ett vanligt val av protokoll. I fallet med en enkärnig processor bestod varje cachelinje av en valid bit. Denna del, cachelinjens tillståndsdel, är vidareutvecklad i MESI för att kunna stödja flertal kärnor och cache koherens. Grundkonceptet gäller fortfarande, att alla cachelinjer kan betraktas som modifierade eller
rena (eng. clean). Skillnaden är att beroende på hur lokalkärnan eller andra kärnor interagerar (read respektive write, se figur 2) med en viss cachelinje ändras tillståndet. I MESI finns det fyra tillstånd: Modified Likt i det enkärniga fallet är detta en modifierad cachelinje som inte är i enlighet med minnet. Vid ersättning måste cachelinjen skrivas till minnet. Exclusive En ren cachelinje som är garanterat exklusiv för cacheminnet den befinner sig i. Shared Tillståndet är detsamma som exklusiv men har blivit avläst och finns möjligen i något annat cacheminne. Om cachelinjen förändras måste cacheminnen som delar just denna cachelinje meddelas. Invalid Datan är ogiltig (Rolf, 2009:2-3). Figur 2 Ett MESI tillståndsdiagram (2007) För att kommunicera med varandra används oftast en gemensam buss (Patterson, 2014:468). På sådant sätt agerar cacheminnet mer enhetligt och blir därmed mer oberoende av det långsamma minnet. MESIF protokollet introducerade ett nytt tillstånd: forward. Forward är en vidareutveckling på tillståndet shared. Tidigare har problemet med shared varit att vid cachelinjeförfrågan svarade samtliga kärnor med att de har eftersökt cachelinje. I MESIF bär cachelinjen med forwardtillståndet ansvaret för att dela cachelinjen vid förfrågan. På så sätt minskas trafiken mellan kärnorna (Rolf, 2009:3). Translation Lookaside Buffer Translation Lookaside Buffer (TLB) är en minnesteknik som är viktig för en processors prestanda. Här introduceras TLB konceptuellt och hur det har implementerats i Nehalem. TLB är en höghastighetsbuffert som mappar virtuella adresser till fysiska adresser i cacheminnet eller minnet. Trots att detta är fullt möjligt utan en TLB så är det inte önskvärt eftersom det skulle kunna leda till att man behöver arbeta med minnet mer än nödvändigt: dels för att leta upp mappningen från den virtuella adressen till den fysiska adressen och dels för att faktiskt hämta data från det fysiska minnet. Med TLB är det möjligt att bortse från att behöva leta i minnet efter mappningen och istället låta TLB lagra mappningen. Rent fysiskt är TLB ett specialiserat cacheminne. Den är specialiserad på så sätt att den innehåller en delmängd av data som mappar virtuell adress till fysisk adress i minnet. Likt hur ett vanligt cacheminne fungerar med skrivstrategier, hantering av cache hit och cache miss och associativitet så fungerar ett TLB på ett liknande sätt. TLB har använts ofta i äldre processorarkitekturer men med Nehalem krävdes större förändringar då Nehalems arkitektur har en mer sofistikerad struktur. En sekundär TLB introducerades, kallad STLB, som kan översätta sidor (eng. pages) i minnet bestående av både instruktioner och data. STLB:n i Nehalem har 512 tillgängliga platser för lagring och stödjer sidor som är upp till 1 GB stora (Dixon et al, 2010:17-18).
Diskussion och sammanfattning Denna rapport har gett en överblick på hur Nehalems cachearkitektur ser ut och vilka tekniker Intel har valt att vidareutveckla från Core-arkitekturen. Att inkludera flera kärnor i en processorer är en kraftfull teknik för att förbättra prestanda, men likt mycket annat inom teknik tillkommer ett pris. Som det har diskuterats hittills finns det mycket att ta hänsyn till. Inom cacheminnen är det exempelvis koherens, trafikbelastning, cachestruktur och protokoll som är speciellt viktiga för multicore processorer. Med alla dessa lösningar på problemen som Core-arkitekturen led av så återstår frågan om vilka problem som fortfarande kvarstår i Nehalem-arkitekturen. Nehalem har bevisats vara väldigt tillförlitlig och har många starka sidor (Rolf, 2009:8). Ett problem som Molka et al skriver om i Memory Performance and Cache Coherency Effects on an Intel Nehalem Multiprocessor System, publicerad 2009, är att cacheminnet på L3 agerar flaskhals när alla fyra kärnor i ett mikrochip skriver eller läser samtidigt (Molka et al, 2009:270). En annan fråga är huruvida Intels största konkurrent inom processorer, AMD, lyckas hålla sig i marknaden. Enligt studier ska AMD:s marknadsandelar ökat i samband med Nehalems lansering (Reuters, 2009). Detta kopplar jag till rapporten då min fråga är om det är en teknisk betingelse som har orsakat denna stigning till AMD:s fördel, som kan betyda att AMD fortfarande hade stor relevans inom mikroprocessorteknik, eller om det rör sig om något annat.
Källförteckningar Fakta 1. 'AMD Market Share Leaps Forward, Intel Maintains Dominance' 2009, Channel Insider, p. 1, Business Source Complete, EBSCOhost, viewed 7 December 2015. 2. Molka, D, Hackenberg, D, Schöne, R, & Müller, M 2009, 'Memory performance and cache coherency effects on an intel nehalem multiprocessor system', Parallel Architectures And Compilation Techniques - Conference Proceedings, PACT, Proceedings - 2009 18th International Conference on Parallel Architectures and Compilation Techniques, PACT 2009, p. 261-270, Scopus, EBSCOhost, viewed 2 December 2015. 3. Awasthi, M, Nellans, D, Sudan, K, Balasubramonian, R, & Davis, A 2012, 'Managing Data Placement in Memory Systems with Multiple Memory Controllers', International Journal Of Parallel Programming, 40, 1, pp. 57-83, Academic Search Complete, EBSCOhost, viewed 7 December 2015. 4. Dixon, M, Hammarlund, P, Jourdan, S & Singhal, R 2010, The Next Generation Intel Core Microarchitecture, Intel Technology Journal, volume 14, issue 3, pp. 8-28, URL: http://www.intel.com/content/dam/www/public/us/en/documents/research/2010-vol14- iss-3-intel-technology-journal.pdf, viewed 2 December 2015. 5. Rolf, T, 2009, Cache Organization and Memory Management of the Intel Nehalem Computer Architecture, CS 6810 Final Project, University of Utah Computer Engineering 6. Jaleel, A, Borch, E, Bhandaru, M, Steely Jr., S, & Emer, J 2010, 'Achieving non-inclusive cache performance with inclusive caches: Temporal Locality Aware (TLA) cache management policies', Proceedings Of The Annual International Symposium On Microarchitecture, MICRO, Proceedings - 43rd Annual IEEE/ACM International Symposium on Microarchitecture, MICRO 2010, p. 151-162, Scopus, EBSCOhost, viewed 2 December 2015. 7. Hennessy, JL, Patterson, DA 2014, Computer Organization and Design: The Hardware/Software Interface, Elsevier, The Boulevard, Langford Lane, Kidlington, Oxford. Grafik 1. Figur 1. En åttakärnig Nehalem processor (2009) [digital image] At: http://rolfed.com/nehalem/nehalempaper.pdf, viewed 2 December 2015. 2. Figur 2. Ett MESI tillståndsdiagram (2007) [digital image] At: https://www.cs.tcd.ie/jeremy.jones/vivio/caches/mesihelp.htm, viewed 2 December 2015.