Enligt vad jag har läst från två olika källor krävs cache-färgning (var?) för att:
-
Motverka problemet med aliasing: Förhindra två olika virtuella adresser med samma fysiska adress från mappning till olika cachesatser . (Enligt ett CS Stack Exchange-svar )
-
Utnyttja den geografiska lokalitetsegenskapen för virtuellt minne : genom att garantera att två intilliggande block av virtuellt minne (inte nödvändigtvis angränsar i fysiskt minne), inte mappar till samma cache-index. (Enligt Wikipedia )
Dessa verkar för mig vara fundamentalt olika definitioner och utan att förstå motivering för cachefärgning, jag verkar inte förstå mekanismen för att välja antal färger som krävs. Är de verkligen en och samma?
Om den virtuella minnets geografiska lokalitet är den främsta motivationen, är cache-färgning krävs verkligen för VIPT-cacher, där cache-indexet härleds från det virtuella minnet till att börja med? Eller används cache-färgning helt enkelt i VIPT-cacher för att komma runt aliasing?
Svar
Både att undvika alias och att undvika alltför stora cachekonflikter är giltiga skäl för att använda sidfärgning. Att kräva sidfärgning för att undvika alias är opopulärt eftersom det sätter en obligatorisk begränsning för sidallokering. allmänt, moderna icke-inbäddade processorer behöver inte sidfärgning för att undvika aliasing.
Undvik aliasingproblem i hårdvara i n ökar hårdvarukomplexiteten, så tidigare processorer (och kanske några senare inbäddade processorer) valde att belasta programvaran. Hårdvara kan undvika aliaseringsproblem i en cache med fler index + offsetbitar än bitar i sidoförskjutning genom (till exempel):
- kontrollera alternativa uppsättningar på en cache-miss (som gjorts av AMDs Athlon; när ett alias upptäcktes flyttades blocket till det aktuella virtuella indexet)
- inklusive de virtuella adressbitarna som används för att indexera L1 i en (tagg) inklusive L2 (vid en L1-miss och L2-träff, om de virtuella adressbitarna matchar motsvarande bitar för begäran, ingen åtgärd är nödvändig. om bitarna inte matchar är den lämpliga inställningen för sond känd [om blocket också finns i L1 kan också lagras i L2-taggarna för att minska koherensen overhead, så vissa sonder kan undvikas])
- med hjälp av inställd förutsägelse för att gissa de extra fysiska adressbitarna som används för indexering (en felberäkning skulle upptäckas efter TLB-åtkomst och korrigeras)
- med omvänd översättning (fysisk till virtuell) på en cachemiss för att hitta möjliga alias (jag tror att en PA-RISC-implementering använde omvänd översättning på för koherens )
Att använda sidfärgning för att minska konflikter (för cachar med enkel modulo med två indexeringseffekter) är mindre opopulär eftersom sidfärgning inte krävs för korrekthet. Om en viss färg blir knapp kan en sida missfärgas med endast en möjlig minskning av prestanda. Denna motivering för sidfärgning innebär också att antalet färgade bitar är mindre begränsade. Det (mindre praktiska) idealet kan vara att matcha alla fysiska indexbitar för den sista nivåcachen med motsvarande virtuella adressbitar, men även färgning av bara fyra bitar kan väsentligt minska konfliktproblem.
Det kan vara värt att notera att färgning för att undvika alias inte behöver matcha virtuella adressbitar med fysiska adressbitar. Så länge alla potentiella alias delar samma virtuella adressbitar som används för indexering undviks aliasproblem. Att matcha fysiska och virtuella adressbitar kan dock vara bekvämt (och ge förutsägbar konflikt i fysiskt adresserade nivåer av cache).