Conform celor citite din două surse diferite, este necesară (era?) colorarea cache-ului pentru:
-
Contrastați problema aliasării: Preveniți două adrese virtuale diferite cu aceeași adresă fizică de la mapare la diferite seturi de cache . (Conform unui CS Stack Exchange Answer )
-
Exploatați proprietatea localității spațiale a memoriei virtuale : garantând că două blocuri adiacente de memorie virtuală (nu neapărat adiacente în memoria fizică), nu mapează la același index cache. (Conform Wikipedia )
Acestea mi se par a fi definiții fundamental diferite și fără a înțelege motivația pentru colorarea cache-ului, nu pot să înțeleg mecanismul de selectare a numărului de culori necesare. Sunt într-adevăr una și aceeași?
Dacă localitatea spațială a memoriei virtuale este motivația principală, este colorarea cache-ului este cu adevărat necesară pentru cache-urile VIPT, unde indexul cache-ului este derivat din memoria virtuală pentru a începe?
Atât evitarea pseudonimelor, cât și evitarea conflictelor excesive în memoria cache sunt motive valabile pentru utilizarea colorării paginilor. Cererea colorării paginilor pentru a evita pseudonimele este nepopulară, deoarece pune o constrângere obligatorie asupra alocării paginilor. în general, procesoarele moderne care nu sunt încorporate nu necesită colorarea paginilor pentru a evita aliasarea.
Evitarea problemelor de aliasare în hardware i ncrește complexitatea hardware-ului, astfel încât procesoarele anterioare (și poate unele procesoare încorporate mai recente) au ales să plaseze povara asupra software-ului. Hardware-ul poate evita problemele de aliasare într-o memorie cache cu mai mulți biți index + offset decât biți în pagina offset prin (de exemplu):
- verificarea seturilor alternative pe o memorie cache (așa cum se face de către AMD Athlon; când a fost detectat un alias, blocul a fost mutat la indexul virtual curent)
- incluzând biții de adresă virtuală utilizați pentru indexarea L1 într-o (etichetă) inclusiv L2 (la o lovitură L1 și la o lovitură L2, dacă biții de adresă virtuală se potrivesc cu biții corespunzători pentru cerere, nu este necesară nicio acțiune; dacă biții nu se potrivesc, se știe setul adecvat de sondare [dacă blocul este și în L1 ar putea fi stocat și în etichetele L2 pentru a reduce coerența overhead, deci s-ar putea evita unele sonde])
- folosind predicția setată pentru a ghici biții de adresă fizică suplimentari utilizați pentru indexare (o predicție greșită ar fi descoperită după accesul TLB și corectată)
- folosind traducerea inversă (fizică în virtuală) pe o memorie cache pentru a găsi posibile pseudonime (cred că o implementare PA-RISC a folosit traducere inversă on pentru coerență )
Folosirea colorării paginilor pentru a reduce conflictele (pentru cache-urile cu modul simplu o putere de două indexări) este mai puțin nepopulară deoarece nu este necesară colorarea paginii pentru corectitudine. Dacă o anumită culoare devine redusă, o pagină poate fi colorată greșit doar cu o posibilă reducere a performanței. Acest motiv pentru colorarea paginilor înseamnă, de asemenea, că numărul de biți colorați este mai puțin constrâns. Idealul (mai puțin practic) poate fi acela de a potrivi toți biții de index fizici pentru memoria cache de ultimul nivel cu biții de adresă virtuali corespunzători, dar chiar și colorarea a doar patru biți poate reduce substanțial problemele de conflict.
Ar putea fi demn de remarcat acea colorare pentru evitarea aliasului nu trebuie să se potrivească cu biții de adresă virtuali cu biții de adresă fizici. Atâta timp cât toate aliasurile potențiale au aceleași biți de adresă virtuală utilizați pentru indexare, problemele legate de alias sunt evitate. Cu toate acestea, potrivirea biților de adresă fizică și virtuală poate fi convenabilă (și poate oferi un conflict previzibil în nivelurile de cache adresate fizic).