Két különböző forrásból olvasottak szerint a gyorsítótár színezése szükséges (volt?) ahhoz, hogy:
-
Megoldja az álnevezés problémáját: Megakadályozza, hogy ugyanazon fizikai címmel két különböző virtuális cím társuljon különböző gyorsítótár-készletekhez . (A CS veremcsere válasza szerint )
-
Használja ki a virtuális memória térbeli lokalitási tulajdonságait : garantálva, hogy a virtuális memória két szomszédos blokkja (nem feltétlenül szomszédos a fizikai memóriával) ne azonos térképre kerüljön. (A Wikipédia szerint)
Ezek számomra alapvetően eltérő definícióknak tűnnek, és nem értik a a gyorsítótár színezésének motivációja, úgy tűnik, nem értem a szükséges színszám kiválasztásának mechanizmusát. Tényleg egyek és ugyanazok?
Ha a virtuális memória térbeli elhelyezkedése az elsődleges motiváció, gyorsítótár-színezés valóban szükséges a VIPT gyorsítótárakhoz, ahol a gyorsítótár indexe eleve a virtuális memóriából származik? Vagy csak a VIPT gyorsítótárakban használják a gyorsítótár színezését az álnév megkerülése érdekében?
Válasz
Az álnevek elkerülése és a túlzott gyorsítótár-ütközések elkerülése is megfelelő ok az oldalszínezés használatára. Az álnevek elkerülése érdekében az oldalszínezés megkövetelése nem népszerű, mert kötelező korlátozást jelent az oldalallokációra. az álnevezés elkerülése érdekében az általános, modern, nem beágyazott processzorok nem igénylik az oldal színezését.
Az álnevezési problémák elkerülése a hardverben i Az n növeli a hardver komplexitását, ezért a korábbi processzorok (és talán néhány újabb beágyazott processzor) úgy döntöttek, hogy a szoftvereket terhelik. A hardverrel elkerülhetők az olyan eltárolási problémák a gyorsítótárban, amelyekben több index + eltolás bit található, mint az oldalon lévő bit (pl.):
- alternatív halmazok ellenőrzése a gyorsítótár kihagyásakor (amint az AMD Athlon; álnév észlelésekor a blokkot áthelyezték az aktuális virtuális indexbe)
- beleértve az L1 indexeléséhez használt virtuális címbiteket egy (tag) befogadó L2-ben (L1 hiányzó és L2 találat esetén, ha a virtuális címbitek megegyeznek a kérés megfelelő bitjeivel, nincs szükség semmilyen műveletre; ha a bitek nem egyeznek, akkor a szondára vonatkozó megfelelő készlet ismert [hogy a blokk L1-es is van-e, az L2 címkékben is tárolhatók a koherencia csökkentése érdekében rezsivel, így elkerülhető lehet néhány szonda])
- a készlet előrejelzésével kitalálni az indexeléshez használt extra fizikai címbiteket (a TLB-hozzáférés után hibajavítást fedeznének fel és javítanának)
- használva fordított fordítás (fizikai-virtuális) gyorsítótár-hiányon, hogy megtalálják a lehetséges álneveket (gondolom, egy PA-RISC megvalósítás fordított fordítást használt be koherencia esetén)
Az oldalszínezés használata az ütközések csökkentésére (egyszerű modulo-val rendelkező gyorsítótárak esetén két indexelés ereje) kevésbé népszerűtlen, mert az oldal színezése nem szükséges a helyességért. Ha egy adott szín ritkul, az oldal hibás színű lehet, csak a teljesítmény esetleges csökkenésével. Az oldalszínezésnek ez az indoka azt is jelenti, hogy a színes bitek száma kevésbé korlátozott. A (kevésbé praktikus) ideális lehet az, ha az utolsó szintű gyorsítótár összes fizikai indexbitjét illesztjük a megfelelő virtuális címbitekkel, de akár csak négy bit színezése is jelentősen csökkentheti az ütközési problémákat.
Érdemes megjegyezni hogy az alias elkerülése érdekében a színezésnek nem kell egyeznie a virtuális címbitekkel a fizikai címbitekkel. Amíg az összes lehetséges álnév ugyanazokkal a virtuális címbitekkel rendelkezik, amelyeket az indexeléshez használnak, az álnevekkel kapcsolatos problémák elkerülhetők. A fizikai és virtuális címbitek egyeztetése azonban kényelmes lehet (és kiszámítható ütközést eredményez a gyorsítótár fizikailag címzett szintjein).