Ifølge hvad jeg har læst fra to forskellige kilder, er (var?) krævet cache-farve for at:
-
Modvirke problemet med aliasing: Forhindre to forskellige virtuelle adresser med den samme fysiske adresse fra kortlægning til forskellige cachesæt . (Ifølge et CS Stack Exchange-svar )
-
Udnyt den geografiske lokalitetsegenskab for virtuel hukommelse : ved at garantere, at to tilstødende blokke af virtuel hukommelse (ikke nødvendigvis støder op i fysisk hukommelse), ikke kortlægges til det samme cacheindeks. (Ifølge Wikipedia )
Disse synes for mig at være fundamentalt forskellige definitioner og uden at forstå motivation for cache-farve, kan jeg ikke synes at forstå mekanismen til valg af antal krævede farver. Er de virkelig en og samme?
Hvis den virtuelle hukommelses rumlige lokalitet er den primære motivation, er cache-farvning virkelig krævet til VIPT-cache, hvor cache-indekset er afledt af den virtuelle hukommelse til at begynde med? Eller bruges cache-farvning simpelthen i VIPT-caches for at komme omkring aliasing?
Svar
Både at undgå aliasser og at undgå overdrevne cachekonflikter er gyldige grunde til at bruge sidefarvning. At kræve sidefarvning for at undgå aliaser er upopulært, fordi det lægger en obligatorisk begrænsning på sidetildeling. generelt, moderne ikke-integrerede processorer kræver ikke sidefarvning for at undgå aliasing.
Undgå aliasingproblemer i hardware i n øger hardwarekompleksiteten, så tidligere processorer (og måske nogle nyere integrerede processorer) valgte at lægge byrden på software. Hardware kan undgå aliasing af problemer i en cache med flere index + offset bits end bits i side offset ved (for eksempel):
- kontrol af alternative sæt på en cache miss (som gjort af AMD “s Athlon; når et alias blev opdaget, blev blokken flyttet til det aktuelle virtuelle indeks)
- inklusive de virtuelle adressebit, der blev brugt til indeksering af L1 i et (tag) inklusive L2 (på et L1-miss og L2-hit, hvis de virtuelle adressebits matcher de tilsvarende bits til anmodningen, ingen handling er nødvendig; hvis bitene ikke stemmer overens, er det passende sæt til sonde kendt [om blokken også er i L1 kunne også lagres i L2-tags for at reducere sammenhæng overhead, så nogle sonder kan undgås])
- ved hjælp af indstillet forudsigelse for at gætte de ekstra fysiske adressebit, der bruges til indeksering (en forkert forudsigelse ville blive opdaget efter TLB-adgang og korrigeret)
- ved hjælp af omvendt oversættelse (fysisk til virtuel) på en cache savner for at finde mulige aliasser (jeg tror, at en PA-RISC-implementering brugte omvendt oversættelse til for sammenhæng )
Brug af sidefarvning til at reducere konflikter (for cacher med enkel modulo med en effekt på to indekseringer) er mindre upopulær, fordi sidefarvning ikke er påkrævet for korrekthed. Hvis en bestemt farve bliver knappe, kan en side misfarves med kun en mulig reduktion i ydeevne. Denne begrundelse for sidefarvning betyder også, at antallet af farvede bits er mindre begrænset. Det (mindre praktiske) ideal kan være at matche alle fysiske indeksbits til det sidste niveau cache med de tilsvarende virtuelle adressebit, men selv farvning af kun fire bits kan reducere konfliktproblemer væsentligt.
Det kan være værd at bemærke at farvning for aliasundgåelse ikke behøver at matche virtuelle adressebit med fysiske adressebit. Så længe alle potentielle aliasser deler de samme virtuelle adressebit, der bruges til indeksering, undgås aliasproblemer. At matche fysiske og virtuelle adressebit kan imidlertid være praktisk (og give forudsigelig konflikt i fysisk adresserede niveauer af cache).