I henhold til det jeg har lest fra to forskjellige kilder, er (var?) fargebuffer nødvendig for å:
-
Motvirke problemet med aliasing: Forhindre to forskjellige virtuelle adresser med samme fysiske adresse fra kartlegging til forskjellige cache-sett . (I følge et CS Stack Exchange Answer )
-
Utnytt den romlige lokalitetsegenskapen til virtuelt minne : ved å garantere at to tilstøtende blokker av virtuelt minne (ikke nødvendigvis tilstøtende i fysisk minne), ikke tilordnes til samme cacheindeks. (I henhold til Wikipedia )
Disse synes jeg er fundamentalt forskjellige definisjoner, og uten å forstå motivasjon for hurtigbufferfarging, jeg ser ikke ut til å forstå mekanismen for å velge antall farger som kreves. Er de virkelig en og samme?
Hvis den romlige lokaliteten til virtuelt minne er den viktigste motivasjonen, er hurtigbufferfarging er virkelig nødvendig for VIPT-hurtigbuffere, hvor indeksen til hurtigbufferen er hentet fra det virtuelle minnet til å begynne med? Eller brukes hurtigbufferfarging bare i VIPT-hurtigbuffer for å komme rundt aliasing?
Svar
Både å unngå aliaser og å unngå overdrevne hurtigbufferkonflikter er gyldige årsaker til å bruke sidefarging. Kreving av sidefarging for å unngå aliaser er upopulær fordi det setter en obligatorisk begrensning for sidetildeling. generelle, moderne ikke-innebygde prosessorer krever ikke sidefarging for å unngå aliasing.
Unngå aliasingproblemer i maskinvare i øker maskinvarekompleksiteten, så tidligere prosessorer (og kanskje noen nyere innebygde prosessorer) valgte å legge byrden på programvaren. Maskinvare kan unngå aliasing av problemer i en cache med flere index + offset bits enn bits i siden offset ved (for eksempel):
- sjekke alternative sett på en cache miss (som gjort av AMDs Athlon; når et alias ble oppdaget, ble blokken flyttet til den nåværende virtuelle indeksen)
- inkludert de virtuelle adressebitene som ble brukt til indeksering av L1 i en (tag) inkludert L2 (på en L1-miss og L2-hit, hvis de virtuelle adressebitene samsvarer med de tilsvarende bitene for forespørselen, ingen handling er nødvendig. Hvis bitene ikke stemmer overens, er det riktige settet til sonde kjent [om blokken også er i L1, kan også lagres i L2-kodene for å redusere koherensen overhead, så noen sonder kan unngås])
- ved å bruke prediksjon for å gjette de ekstra fysiske adressebitene som brukes til indeksering (feil prediksjon vil bli oppdaget etter TLB-tilgang og korrigert)
- ved å bruke omvendt oversettelse (fysisk til virtuell) på en cache, savner å finne mulige aliaser (jeg tror en PA-RISC-implementering brukte omvendt oversettelse på for koherens )
Bruk av sidefarging for å redusere konflikter (for cacher med enkel modulo med en effekt på to indekseringer) er mindre upopulær fordi sidefarging ikke er nødvendig for korrekthet. Hvis en bestemt farge blir knapp, kan en side misfarges med bare en mulig reduksjon i ytelse. Denne begrunnelsen for sidefarging betyr også at antall fargede biter er mindre begrenset. Det (mindre praktiske) idealet kan være å matche alle fysiske indeksbiter for siste nivåbufferen med de tilsvarende virtuelle adressebitene, men selv farging av bare fire biter kan redusere konfliktproblemer vesentlig.
Det kan være verdt å merke seg at farging for å unngå alias ikke trenger å matche virtuelle adressebiter med fysiske adressebiter. Så lenge alle potensielle aliaser har samme virtuelle adressebiter som brukes til indeksering, unngås aliasproblemer. Imidlertid kan det være praktisk å matche fysiske og virtuelle adressebiter (og gi forutsigbar konflikt i fysisk adresserte nivåer av hurtigbuffer).