Según lo que he leído de dos fuentes diferentes, el color de la caché es (¿era?) necesario para:
-
Contrarreste el problema del aliasing: Evite que dos direcciones virtuales diferentes con la misma dirección física se asignen a diferentes conjuntos de caché . (De acuerdo con una CS Stack Exchange Answer )
-
Explote la propiedad de localidad espacial de la memoria virtual : garantizando que dos bloques adyacentes de memoria virtual (no necesariamente adyacentes en la memoria física) no se asignen al mismo índice de caché. (De acuerdo con Wikipedia )
Me parecen definiciones fundamentalmente diferentes, y sin comprender el motivación para colorear caché, parece que no puedo entender el mecanismo para seleccionar el número de colores requeridos. ¿Son realmente uno y el mismo?
Si la localidad espacial de la memoria virtual es la motivación principal, ¿es El color de caché es realmente necesario para los cachés VIPT, donde el índice del caché se deriva de la memoria virtual para empezar, ¿o el color de caché se usa simplemente en los cachés VIPT para evitar el aliasing?
Respuesta
Tanto evitar los alias como evitar excesivos conflictos de caché son razones válidas para usar el color de la página. Requerir el color de la página para evitar los alias es impopular porque impone una restricción obligatoria en la asignación de páginas. En general, los procesadores modernos no integrados no requieren colorear la página para evitar el alias.
Evitar problemas de alias en hardware i Aumenta la complejidad del hardware, por lo que los procesadores anteriores (y quizás algunos procesadores integrados más recientes) optaron por colocar la carga en el software. El hardware puede evitar problemas de alias en un caché con más índices + bits de desplazamiento que bits en el desplazamiento de página al (por ejemplo):
- verificando conjuntos alternativos en una falla de caché (como lo hizo AMD «s Athlon; cuando se detectó un alias, el bloque se movió al índice virtual actual)
- incluidos los bits de dirección virtual utilizados para indexar L1 en una (etiqueta) L2 inclusiva (en una falla L1 y una visita L2, si los bits de la dirección virtual coinciden con los bits correspondientes para la solicitud, no es necesario realizar ninguna acción; si los bits no coinciden, se conoce el conjunto apropiado para sondear [si el bloque también está en L1 también podría almacenarse en las etiquetas L2 para reducir la coherencia sobrecarga, por lo que se podrían evitar algunas sondas])
- usando la predicción establecida para adivinar los bits de dirección física adicionales utilizados para la indexación (se descubriría una predicción errónea después del acceso a TLB y se corregiría)
- usando la traducción inversa (física a virtual) en una caché falla para encontrar posibles alias (creo que una implementación PA-RISC usó traducción inversa on para coherencia )
El uso de colorear de página para reducir conflictos (para cachés con indexación de módulo simple una potencia de dos) es menos impopular porque no es necesario colorear la página por la corrección. Si un color en particular se vuelve escaso, una página puede tener un color incorrecto con solo una posible reducción en el rendimiento. Esta justificación para colorear páginas también significa que el número de bits coloreados está menos restringido. El ideal (menos práctico) puede ser hacer coincidir todos los bits de índice físicos para la caché de último nivel con los bits de dirección virtual correspondientes, pero incluso colorear solo cuatro bits puede reducir sustancialmente los problemas de conflicto.
Puede que valga la pena señalar que los colores para evitar el alias no necesitan coincidir con los bits de direcciones virtuales con los bits de direcciones físicas. Siempre que todos los alias potenciales compartan los mismos bits de dirección virtual utilizados para la indexación, se evitan los problemas de alias. Sin embargo, la coincidencia de bits de dirección física y virtual puede ser conveniente (y proporcionar un conflicto predecible en niveles de caché dirigidos físicamente).