Zgodnie z tym, co przeczytałem z dwóch różnych źródeł, kolorowanie pamięci podręcznej jest (było?) wymagane, aby:
-
Przeciwdziałaj problemowi aliasingu: Zapobiegaj mapowaniu dwóch różnych adresów wirtualnych z tym samym adresem fizycznym do różnych zestawów pamięci podręcznej . (Zgodnie z odpowiedzią wymiany stosu CS )
-
Wykorzystaj właściwość lokalizacji przestrzennej pamięci wirtualnej : gwarantując, że dwa sąsiednie bloki pamięci wirtualnej (niekoniecznie sąsiadujące ze sobą w pamięci fizycznej) nie będą mapowane na ten sam indeks pamięci podręcznej. (Według Wikipedii )
Wydaje mi się, że są to zasadniczo różne definicje i bez pojmowania motywacji do kolorowania pamięci podręcznej, wydaje mi się, że nie rozumiem mechanizmu wyboru wymaganej liczby kolorów. Czy naprawdę są one takie same?
Jeśli przestrzenna lokalizacja pamięci wirtualnej jest główną motywacją, czy Kolorowanie pamięci podręcznej jest naprawdę wymagane w przypadku pamięci podręcznych VIPT, w których indeks pamięci podręcznej pochodzi z pamięci wirtualnej? A może kolorowanie pamięci podręcznej jest po prostu używane w pamięciach podręcznych VIPT w celu obejścia aliasów?
Odpowiedź
Zarówno unikanie aliasów, jak i unikanie nadmiernych konfliktów pamięci podręcznej to ważne powody, dla których warto używać kolorowania stron. Wymaganie kolorowania stron w celu uniknięcia aliasów jest niepopularne, ponieważ nakłada obowiązkowe ograniczenie na alokację stron. ogólnie rzecz biorąc, nowoczesne procesory niewbudowane nie wymagają kolorowania stron, aby uniknąć aliasingu.
Unikanie problemów z aliasami na sprzęcie i nzwiększa złożoność sprzętu, więc wcześniejsze procesory (i być może niektóre nowsze procesory wbudowane) zdecydowały się nałożyć obciążenie na oprogramowanie. Sprzęt może uniknąć problemów z aliasami w pamięci podręcznej z większą liczbą bitów indeksu i przesunięcia niż bitów w przesunięciu strony poprzez (na przykład):
- sprawdzanie alternatywnych zestawów w przypadku braku pamięci podręcznej (tak jak zostało to zrobione przez AMD) Athlon; po wykryciu aliasu blok został przeniesiony do bieżącego indeksu wirtualnego)
- łącznie z wirtualnymi bitami adresu używanymi do indeksowania L1 w (znaczniku) zawierającym L2 (przy chybieniu L1 i trafieniu L2, jeśli bity adresu wirtualnego pasują do odpowiednich bitów żądania, żadne działanie nie jest konieczne; jeśli bity się nie zgadzają, znany jest odpowiedni zestaw do sondowania [czy blok jest również w L1 może być również przechowywany w znacznikach L2 w celu zmniejszenia spójności narzut, więc niektórych sond można uniknąć])
- używanie predykcji zestawu do odgadnięcia dodatkowych bitów adresu fizycznego używanych do indeksowania (błędne przewidywanie zostanie wykryte po uzyskaniu dostępu do TLB i poprawione)
- używając odwrotne tłumaczenie (fizyczne na wirtualne) w pamięci podręcznej brakuje, aby znaleźć możliwe aliasy (myślę, że implementacja PA-RISC wykorzystała odwrotne translati włączone dla spójności )
Używanie kolorowania stron w celu zmniejszenia konfliktów (dla buforów z prostym modulo moc dwóch indeksów) jest mniej niepopularne, ponieważ kolorowanie strony nie jest wymagane dla poprawności. Jeśli brakuje określonego koloru, kolor strony może zostać nieprawidłowo pokolorowany, co powoduje jedynie możliwy spadek wydajności. To uzasadnienie dla kolorowania stron oznacza również, że liczba kolorowych bitów jest mniej ograniczona. (Mniej praktycznym) ideałem może być dopasowanie wszystkich fizycznych bitów indeksu dla pamięci podręcznej ostatniego poziomu z odpowiednimi bitami adresu wirtualnego, ale nawet kolorowanie tylko czterech bitów może znacznie zmniejszyć problemy z konfliktami.
Może warto to zauważyć to kolorowanie dla unikania aliasów nie musi dopasowywać bitów adresu wirtualnego do bitów adresu fizycznego. Dopóki wszystkie potencjalne aliasy mają te same bity adresu wirtualnego używane do indeksowania, unika się problemów z aliasami. Jednak dopasowanie fizycznych i wirtualnych bitów adresu może być wygodne (i zapewniać przewidywalny konflikt w fizycznie adresowanych poziomach pamięci podręcznej).