De acordo com o que li de duas fontes diferentes, a coloração do cache é (era?) necessária para:
-
Contorne o problema de aliasing: Evite que dois endereços virtuais diferentes com o mesmo endereço físico sejam mapeados para conjuntos de cache diferentes . (De acordo com uma CS Stack Exchange Answer )
-
Explorar a propriedade de localidade espacial da memória virtual : garantindo que dois blocos adjacentes de memória virtual (não necessariamente adjacentes na memória física), não sejam mapeados para o mesmo índice de cache. (De acordo com a Wikipedia )
Estas parecem-me ser definições fundamentalmente diferentes, e sem compreender o motivação para colorir o cache, não consigo entender o mecanismo para selecionar o número de cores necessárias. Elas são realmente uma só e a mesma?
Se a localidade espacial da memória virtual é a principal motivação, é A coloração do cache é realmente necessária para caches VIPT, onde o índice do cache é derivado da memória virtual para começar? Ou a coloração do cache é simplesmente usada em caches VIPT para contornar o aliasing?
Resposta
Evitar apelidos e conflitos excessivos de cache são razões válidas para usar coloração de página. Requerer coloração de página para evitar apelidos é impopular porque impõe uma restrição obrigatória na alocação de páginas. em geral, os processadores modernos não incorporados não exigem cores de página para evitar aliasing.
Evitando problemas de aliasing no hardware i aumenta a complexidade do hardware, então os processadores anteriores (e talvez alguns processadores embarcados mais recentes) optaram por colocar a carga no software. O hardware pode evitar problemas de aliasing em um cache com mais bits de índice + deslocamento do que bits no deslocamento de página (por exemplo):
- verificando conjuntos alternativos em uma falha de cache (como feito por AMD “s Athlon; quando um alias foi detectado, o bloco foi movido para o índice virtual atual)
- incluindo os bits de endereço virtual usados para indexar L1 em uma (tag) inclusive L2 (em uma falha L1 e acerto L2, se os bits de endereço virtual combinam com os bits correspondentes para a solicitação, nenhuma ação é necessária; se os bits não combinam, o conjunto apropriado para sondar é conhecido [se o bloco também está em L1 também pode ser armazenado nas tags L2 para reduzir a coerência sobrecarga, então algumas sondagens podem ser evitadas])
- usando predição de conjunto para adivinhar os bits de endereço físico extras usados para indexação (uma predição errada seria descoberta após o acesso TLB e corrigida)
- usando tradução reversa (física para virtual) em uma falha de cache para encontrar possíveis aliases (acho que uma implementação PA-RISC usou a tradução reversa para coerência )
Usar a coloração de página para reduzir conflitos (para caches com módulo simples um poder de indexação de dois) é menos impopular porque a coloração de página não é necessária para correção. Se uma cor específica se tornar escassa, uma página pode ficar com cores incorretas, apenas com uma possível redução no desempenho. Essa justificativa para a coloração de páginas também significa que o número de bits coloridos é menos restrito. O ideal (menos prático) pode ser combinar todos os bits de índice físico para o cache de último nível com os bits de endereço virtual correspondentes, mas mesmo colorir apenas quatro bits pode reduzir substancialmente os problemas de conflito.
Pode ser interessante notar essa coloração para evitar alias não precisa corresponder aos bits de endereço virtual com bits de endereço físico. Contanto que todos os aliases potenciais compartilhem os mesmos bits de endereço virtual usados para indexação, os problemas de alias são evitados. No entanto, combinar bits de endereço físico e virtual pode ser conveniente (e fornecer conflito previsível em níveis fisicamente endereçados de cache).