Cachekoherens i flerkärniga processorer: hur den underhålls och vem kontrollerar den

Informatec Digital » Resurser » Cachekoherens i flerkärniga processorer: hur den underhålls och vem kontrollerar den

När man tittar på ett diagram över en modern flerkärnig processor, framträder alltid samma mönster: flera kärnor, var och en med sina egna närliggande cacheminnen, och en delad sista-nivå-cache som fungerar som en gemensam punkt innan den når RAM-minnet. Detta arrangemang är inte en slump eller ett infall från konstruktörerna, utan ett direkt svar på ett kritiskt problem i parallella system: cachekoherens.

Utan en robust konsistensmekanism kan varje kärna sluta med att arbeta med en annan och föråldrad version av samma data i minnet , vilket i ett verkligt program leder till subtila fel, oförutsägbara fel och till och med systemkrascher. Därför är det viktigt att förstå hur denna konsistens upprätthålls – både på hårdvaru- och mjukvarunivå – för att förstå prestandan och stabiliteten hos moderna flerkärniga processorer.

Vad är cachekoherens: terminalmetaforen

Tänk dig flera personer som sitter framför olika terminaler och alla redigerar samma dokument som lagras på en central server . Varje skärm visar en kopia av filen, och alla ändringar som en person gör förväntas återspeglas omedelbart på alla andras skärmar.

För att detta ska fungera behöver det finnas en synkroniseringsmekanism som sprider dokumentändringar till alla terminaler, så att alla alltid ser samma version. Så länge det här systemet fungerar är allt bra: den som ändrar texten vet att alla andra kommer att se den nya versionen nästan omedelbart.

Tänk dig nu att synkroniseringssystemet plötsligt slutar fungera. Varje person fortsätter att redigera, övertygad om att de arbetar med det delade dokumentet, men i verkligheten har varje terminal sin egen frånkopplade lokala kopia . Från och med det ögonblicket når ändringar som gjorts av en person inte de andra, och dokumentet börjar divergera okontrollerat.

Inom databehandling är det just detta som skulle hända om processorn saknade ett tillförlitligt konsistensprotokoll: en kärna modifierar data i minnet, men de andra kärnorna fortsätter att läsa en äldre version från sina privata cacher . Detta skapar grogrund för allvarliga logiska fel, korrupt data och felsökning.

Cachekoherens är därför den uppsättning mekanismer som säkerställer att alla kopior av samma data, distribuerade över de olika cacheminnorna och RAM-minnet, bibehåller ett konsekvent tillstånd i ett flerkärnigt system. Även om det finns flera kopior måste systemet bete sig "som om" det bara fanns en.

Cacher och minneshierarki i en flerkärnig CPU

CPU-cacher är små, mycket snabba minnen som innehåller kopior av ofta använda RAM-minnen . När processorn kör kod, istället för att kontinuerligt komma åt (jämförelsevis långsamt) RAM, försöker den läsa från och skriva till cachen, vilket drastiskt minskar latensen.

Tricket är förstås att cacher inte lagrar den "officiella versionen" av data, utan bara en tillfällig replika . Enligt terminalmetaforen skulle RAM vara dokumentet på servern, medan cacher skulle vara de lokala skärmarna som visar kopior av vissa delar av filen.

I en flerkärnig CPU blir designen mer komplex eftersom varje kärna vanligtvis har sina egna privata nivå 1-cacher (L1) och till och med nivå 2-cacher (L2) . Ovanför dessa läggs till en delad nivå 3-cache (till exempel), placerad mellan kärnorna och minneskontrollern som ger åtkomst till RAM-minnet.

Denna delade cache introduceras eftersom det skulle orsaka åtkomstkonflikter, konkurrens på minnesbussen och en betydande prestandaminskning om alla kärnor fick direkt och intensiv åtkomst till RAM . Cachen på sista nivån fungerar som en gemensam "buffert" som minskar RAM-åtkomst och centraliserar mycket av datatrafiken.

Dessutom organiserar många arkitekturer cacher inkluderande: rader som lagras på nivåer nära processorn finns också på högre nivåer i hierarkin . Det vill säga, en rad som visas i L1 finns också i L2 och i sin tur i L3. Detta har en mycket användbar konsekvens för konsistensen: att helt enkelt uppdatera cachen på lägsta nivå korrekt räcker för att kontrollera tillståndet för de andra nivåerna utan att ständigt behöva komma åt RAM.

Varför delad cachning på sista nivån är nyckeln till konsekvens

Utan denna globala cache på sista nivån skulle varje kärna behöva kontrollera konsistensen direkt mot huvudminnet . Varje gång en minnesrad i en privat cache ändrades skulle det vara nödvändigt att kontrollera om andra kärnor har en kopia av samma rad och, i så fall, uppdatera eller ogiltigförklara den överallt.

I ett system med många kärnor skulle denna arbetsbelastning av kontroller resultera i ett enormt antal transaktioner till RAM-minnet , vilket skulle omintetgöra mycket av fördelen med att ha snabba cacher. Genom att placera en delad cache mellan kärnorna och minnet kan processorn koncentrera koherenskontrollen på en enda mellanliggande plats.

I många implementeringar innehåller cacharna på högre nivåer (längre bort från processorn) kopior av raderna som finns i nivåerna närmare kärnan . Med denna organisation behöver koherensprotokollet bara säkerställa att den sista nivån är synkroniserad med huvudminnet, och att de privata nivåerna för varje kärna är synkroniserade med nivån omedelbart ovanför den.

Detta kan visualiseras som en sorts rysk docka: den tredje nivåns cache innehåller innehållet från den andra och första nivån , den andra nivån innehåller sitt eget innehåll och innehållet från den första nivån, och den första nivån känner bara till sina egna linjer. Genom att kontrollera den "stora dockan" (den sista nivån) kan systemet således koordinera resten mer effektivt.

Resultatet är att det blir mer ekonomiskt att upprätthålla konsistens när det gäller design och minnestrafik . Istället för att tvinga varje kärna att ständigt hantera RAM, fungerar protokollet på den delade cachen och styr därifrån vilka rader som ska uppdateras eller ogiltigförklaras i de privata cacherna.

Uppdateringsmetoder: ogiltigförklaring och uppdatering av kopior

Ett kritiskt problem uppstår när två eller flera kärnor vill komma åt, nästan samtidigt, samma datarad som replikeras över flera cacher . I detta sammanhang använder konsistenssystem vanligtvis två grundläggande strategier vid hantering av skrivningar.

Den första metoden är baserad på ogiltigförklaring. När en kärna behöver skriva till en specifik cacherad ogiltigförklarar protokollet alla kopior av samma rad som kan finnas i de andra cacharna . Endast kärnan som ska skriva håller raden i ett läs- och skrivaktiverat tillstånd; de andra, om de vill använda den informationen igen, måste ladda om raden från den högre nivån (eller från minnet) med den uppdaterade versionen.

Den andra strategin involverar uppdatering. I det här fallet, när en kärna ändrar en rad, försöker systemet automatiskt sprida det nya innehållet till befintliga kopior i de andra cacharna . På så sätt får alla cacher som lagrade den raden den uppdaterade versionen utan att behöva ogiltigförklara och ladda om den senare.

Varje metod har sina för- och nackdelar. Ogiltigförklaring är vanligtvis mer effektiv när skrivningar sker ofta eftersom det undviker att mätta minnessystemet med uppdateringar som andra kärnor kanske inte omedelbart behöver. Omvänt kan uppdatering vara fördelaktigt när många kärnor ofta läser samma data som ändras relativt sällan , eftersom det minskar latensen genom att inte behöva ladda om raden efter varje ogiltigförklaring.

I båda fallen använder båda metoderna ytterligare tillstånd och kontrollbitar i cache-raderna. Varje rad innehåller vanligtvis information om huruvida dess innehåll matchar innehållet i RAM , och om den är delad, modifierad, exklusiv, reserverad etc., beroende på det specifika protokollet (MESI, MOESI, MSI, etc.). Detta gör att hårdvaran kan fatta snabba beslut om vad som ska göras när en läs- eller skrivoperation sker på en redan replikerad linje.

Kontrollera konsistens mellan cacher och minne

Att direkt verifiera konsistensen mellan alla cachenivåer i en processor eller grafikkort och huvudminnet skulle vara en enorm uppgift, både vad gäller designkomplexitet och prestandakostnad. Därför organiserar moderna system denna verifiering hierarkiskt.

Cacheminnorna närmast processorn (L1, L2) är vanligtvis inte direkt anslutna till RAM-minnet, utan till nästa cachenivå. Detta innebär att konsistensen inte valideras mot huvudminnet på varje nivå, utan snarare mot den omedelbart högre nivån . Detta minskar antalet RAM-åtkomster och förenklar logiken som krävs på lägre nivåer.

Slutligen utförs jämförelsen mellan cacheinnehåll och RAM-innehåll mellan den sista nivåns cache och huvudminnet . Om denna sista nivå upprätthåller ett korrekt och konsekvent tillstånd, och varje lägre nivå upprätthåller sin konsistens med den ovanför, förblir hela hierarkin konsekvent utan att varje rad behöver kontrolleras mot RAM upprepade gånger.

När en kärna skriver till en cacherad och ändrar sina data, markeras radens tillstånd för att indikera att den inte längre exakt matchar kopian som lagras i minnet . Därifrån koordinerar protokollet uppdateringen: det markerar motsvarande kopior i andra cacher som reserverade eller ogiltiga och, när det är lämpligt, skriver det nya innehållet till den tillhörande huvudminnesraden.

Denna kaskadstruktur gör att ändringar kan fortplanta sig progressivt från kärnan, som uppdaterar data, till huvudminnet och passera genom varje cachenivå på ett kontrollerat sätt. På så sätt blir upprätthållandet av konsistens inte en oöverstiglig flaskhals för processorn.

Hårdvarukorrelation kontra mjukvarukorrelation

Hittills har vi diskuterat konsistensmekanismer som huvudsakligen implementeras i hårdvara: protokoll, statusbitar, delade cacher etc. Det finns dock ett annat tillvägagångssätt som syftar till att flytta en del av den komplexiteten till programvara , specifikt till kompilatorn och operativsystemet.

Programvarubaserade konsistensscheman försöker minska behovet av ytterligare logik på chipet genom att analysera kod och fatta beslut vid kompileringstid . Tanken är att om kompilatorn kan härleda när och hur vissa delade data nås, kan den i många fall förhindra att dessa data cachas eller explicit hantera dess synlighet.

Denna metod har en tydlig fördel: en del av arbetsbelastningen skiftar från lösning vid körning till lösning vid kompilering . Istället för att hårdvaran ska upptäcka och hantera alla konflikter i farten, försöker kompilatorn förutse dem och generera kod som undviker farliga situationer.

Nackdelen är att statisk kodanalys är begränsad, och därför tenderar kompilatorer att vara konservativa . Det betyder att de, för att undvika att bryta mot konsekvensen, ofta fattar beslut som minskar cacheminnens effektivitet. Om de misstänker att viss data kan vara problematisk, förhindrar de ofta att den cachas eller tvingar fram synkroniseringar oftare än absolut nödvändigt.

Därför, även om dessa programvaruscheman är attraktiva i teorin, särskilt för att förenkla hårdvarudesign, ersätter de i praktiken inte koherensstödet som är integrerat i själva processorn , utan kompletterar det snarare i vissa specifika scenarier.

Kompilatorns roll i cachekonsistens

En viktig del av programvarubaserade konsistensmetoder är kompilatorns roll. Kompilatorn kan utföra en djupgående analys av koden och avgöra vilka delade datastrukturer som kan vara osäkra för cachning . Baserat på detta markerar den dessa element på ett särskilt sätt eller anpassar kodgenereringen.

Det enklaste, och även det mest konservativa, tillvägagångssättet är att förhindra att delade datavariabler cachas . Det vill säga att varje åtkomst till dessa variabler tvingar fram åtkomst till huvudminnet eller ett icke-cachningsbart område. Detta garanterar konsekvens, men missar många prestandamöjligheter, eftersom en delad struktur faktiskt kan användas privat under vissa perioder, eller skrivskyddad under andra.

I verkligheten uppstår konsistensproblemet bara under intervaller då minst en process kan skriva till variabeln och en annan process kan läsa den . Utanför dessa kritiska perioder kan variabeln behandlas som om den uteslutande är avsedd för en enda tråd eller till och med som en effektiv konstant under en tid, vilket gör att den kan cachas utan problem.

De mest avancerade kompileringsstrategierna försöker identifiera de "säkra" perioder under vilka den delade variabeln kan anses vara icke-konfliktfylld . För att göra detta analyserar kompilatorn exekveringsvägar, potentiella samtidiga åtkomster och synkroniseringsmönster (lås, kritiska avsnitt, etc.). Baserat på denna analys delar den upp variabelns livslängd i faser: vissa är lämpliga för cachning, andra kräver särskild hantering.

Under kritiska perioder, när samtidig åtkomst med skrivningar upptäcks, infogar kompilatorn ytterligare instruktioner i den genererade koden för att upprätthålla cachekonsekvens . Dessa instruktioner kan tvinga fram cache-rensningar, minnesomladdningar, minnesbarriärer eller åtkomst till regioner markerade som icke-cachebara, beroende på programmeringsmodellen och den underliggande arkitekturen.

Sambandet mellan kompilator, operativsystem och hårdvara

Frasen "kompilatorn infogar instruktioner i den genererade koden för att säkerställa cachekonsekvens" kan få en att tro att operativsystemet läser dessa instruktioner som om de vore tips på hög nivå och, baserat på det, bestämmer hur programmet ska köras. I verkligheten är mekanismen något annorlunda.

När kompilatorn lägger till den här typen av instruktioner, introduceras specifika operationer i binärfilen som stöds av arkitekturen eller runtime-miljön . Till exempel kan den infoga instruktioner för cache-rensning, minnesbarriärer, specialinstruktioner för att markera regioner som icke-cachelagrade eller anrop till operativsystemtjänster som konfigurerar minnesattribut.

Operativsystemet tolkar inte dessa instruktioner som övergripande "kommentarer" eller "tips" skrivna av kompilatorn; det kör helt enkelt maskinkoden som vilken annan kod som helst. Vissa av dessa instruktioner är dock utformade för att interagera med minnesundersystemet och cachehanteringen, vilket ändrar hur processorn kommer åt viss data.

Med andra ord utför kompilatorn preliminär analys och genererar kod som, när den körs, producerar önskat cachebeteende . Operativsystemet samarbetar genom att etablera minnesattribut (cachebara eller icke-cachebara områden, skrivpolicyer etc.) och tillhandahålla synkroniseringsprimitiver, men det "läser" inte speciella instruktioner i den meningen att det tolkar dem semantiskt som en kompilator skulle göra.

Det kan också hända att hårdvaran, när den ser vissa instruktioner, aktiverar specifika koherens- eller synkroniseringsmekanismer . Till exempel garanterar staket- eller barriärinstruktioner ordningen för minnesåtkomst och upprätthåller vissa synlighetseffekter över cachehierarkin. I det här fallet finns det ett trevägssamarbete: kompilatorn bestämmer var dessa instruktioner ska placeras, operativsystemet konfigurerar exekveringsmiljön och hårdvaran implementerar det faktiska beteendet på cache- och minnesbussnivå.

Tillsammans säkerställer alla dessa element att parallella program körs med en konsekvent minnesmodell, även med flera kopior av samma data fördelade över olika cacheminnen och huvudminnet. Cachekoherens, långt ifrån att vara en enkel intern CPU-detalj, blir en central komponent för att flerkärniga system ska fungera tillförlitligt och effektivt.

Att förstå hur cachehierarki, hårdvaruprotokoll och programvarusupporttekniker kombineras gör det tydligare varför moderna CPU-designer delar en så likartad struktur, och varför ett litet fel i någon av dessa mekanismer kan utlösa kaotiskt beteende i samtidiga applikationer som helt och hållet är beroende av att alla kärnor ser samma data vid rätt tidpunkt.