¿Se almacenan en caché los recorridos de la tabla de páginas?

En un microprocesador con administración de TLB de hardware (por ejemplo, un Intel x86-64), si se produce una falla de TLB y el procesador está recorriendo la tabla de páginas, ¿estos accesos a la memoria (fuera del chip) pasan por la jerarquía de caché (L1, L2, etc.) )?

Nada que ver con el diseño electrónico. La pregunta se cerrará.
Está preguntando cómo funciona un chip en particular, así que creo que está en el tema.
@OlinLathrop: Estoy de acuerdo: creo que los detalles de bajo nivel de un circuito integrado están en el tema.
Tengo que estar de acuerdo, al menos, que depurar la función de nuestros procesadores es un paso importante para lograr diseñar un sistema determinista decente. Esto se acerca cada vez más a uno de nuestros límites, pero parece fuertemente interior.

Respuestas (2)

Sí, por lo que puedo decir, en los procesadores Intel x86-64, cuando se produce una falla de TLB y el procesador está recorriendo la tabla de páginas, esos accesos a la memoria fuera del chip pasan por la jerarquía de caché.

Todavía estoy un poco confuso con algunos detalles, y espero que alguna otra respuesta los complete. ¿No hay un manual de Intel o AMD que describa la página con detalles insoportables? Mi entendimiento es que:

  • La dirección virtual en algún registro de direcciones se entrega primero a un TLB rápido para convertirla en una dirección física: la dirección en la PC se entrega al L1 ITLB, la dirección en cualquier otro registro se entrega al L1 DTLB .
  • Si esa primera búsqueda falla, se intenta otro nivel de TLB más lento y más grande. (¿Este TLB L2 también se divide en un ITLB y un DTLB, o es un caché TLB unificado? ¿Hay más niveles TLB -- L3 ? L4 ?)
  • Si la búsqueda de TLB falla por completo y el caminante VHPT x86 y x86-64 está deshabilitado, la CPU señala una falla de falta de TLB, que es interceptada por el kernel del sistema operativo. Tengo entendido que prácticamente todas las CPU que no son x86 hacen lo mismo: manejar las fallas de TLB completamente en el software. Si está habilitado, los procesadores x86 y x86-64 tienen un andador de mesa VHPT asistido por hardware que maneja los siguientes pasos. (¿Los chips x86 y x86-64 tienen un bit que deshabilita por completo VHPT, o hay muchos bits que pueden habilitar VHPT para algunos rangos de direcciones y deshabilitar VHPT para otros rangos de direcciones? ¿Dónde están ubicados esos bits?)
  • si la búsqueda de TLB falla por completo, la dirección virtual original (probablemente en modo de usuario) V1 se convierte en V2, la dirección virtual de la entrada de la tabla de páginas PTE que contiene el número de página física para V1.
  • Debido a que V2 es nuevamente una dirección virtual, la CPU realiza la traducción normal de dirección virtual a física, excepto que omite L1 y va directamente a L2.
  • El hardware busca la dirección virtual V2 en el TLB en paralelo con la obtención de ese PTE del caché L2 (virtualmente indexado).
  • Debido a que V2 no es la dirección de una instrucción, no pasa por el caché de instrucciones L1; y debido a que V2 no es la dirección de los datos de usuario normales, no pasa por el caché de datos L1. V2 se introduce inicialmente en la caché unificada L2 (una instrucción unificada+datos+caché PTE). Consulte el "ejemplo de jerarquía de caché" .
  • Si la caché L2 (o L3 o cualquier otra caché indexada virtualmente) contiene el PTE, entonces el VHPT obtiene el PTE de la memoria caché e instala el PTE para V1 en el TLB, y la dirección física en ese PTE se usa para traducir el la dirección virtual original V1 en la dirección de RAM física, y eventualmente obtener esos datos o instrucciones completamente en hardware sin ninguna ayuda del sistema operativo.
  • Si fallan todos los niveles de caché indexada virtualmente, pero esta segunda búsqueda de TLB tiene éxito para V2, entonces el VHPT obtiene la PTE de la caché indexada físicamente o de la memoria principal, instala la PTE para V1 en la TLB y la dirección física en ese PTE se usa para traducir la dirección virtual original V1 a la dirección de RAM física, y eventualmente obtener esos datos o instrucciones completamente en hardware sin la ayuda del sistema operativo.
  • Si esta segunda búsqueda de TLB falla, el caminante VHPT de hardware se da por vencido con una FALLA DE TRADUCCIÓN DE VHPT.
  • Cuando ocurre una FALLA DE TRADUCCIÓN DE VHPT, la CPU se conecta al sistema operativo. El sistema operativo tiene que averiguar qué salió mal y arreglar las cosas:
  • (a) tal vez la página que contiene V2 se haya intercambiado actualmente en el disco, por lo que el sistema operativo la lee en la RAM y reinicia la instrucción fallida, o
  • (b) tal vez un programa con errores está tratando de leer, escribir o ejecutar alguna ubicación no válida, y el sistema operativo finaliza el proceso, o
  • (c) una variedad de otros trucos que hacen los escritores del sistema operativo para usar este mecanismo para atrapar varios tipos de acceso: cargar la página que contiene V1 que puede intercambiarse en el disco; varias trampas utilizadas para depurar nuevos programas; para simular "W^X" en CPU que no lo admiten directamente; para admitir copia en escritura; etc.

El diagrama de la página 2 de Thomas W. Barr, Alan L. Cox, Scott Rixner. "Almacenamiento en caché de traducción: omitir, no caminar (la tabla de página)" que traza una línea entre "Entradas almacenadas por caché de MMU" y "entradas almacenadas por caché de datos L2". (Este puede ser un documento útil para las personas que diseñan nuevas CPU , que es totalmente sobre el tema de "Diseño electrónico").

Stephane Eranian y David Mosberger. "Memoria virtual en el kernel de Linux IA-64" y Ulrich Drepper. "Lo que todo programador debe saber sobre la memoria" (Este puede ser un documento útil para las personas que escriben sistemas operativos que se ocupan de la tabla de páginas IA-64, que está un poco fuera de tema para ED, tal vez Stack Overflow con el "operativo- system" o la etiqueta "osdev" o la wiki de OSDev.org sería un mejor lugar para ese tema).

Tabla A-10 en la página 533 de Intel. "Manual del desarrollador de software de las arquitecturas Intel® 64 e IA-32" "PAGE_WALKS.CYCLES... puede indicar si la mayoría de los paseos por la página se satisfacen con las memorias caché o provocan una pérdida de la memoria caché L2".

Me encanta la respuesta, pero probablemente soy uno de los muchos que no tienen la experiencia necesaria para sentirse cómodos dando lo que probablemente sea un voto a favor bien merecido. Como otros expertos verifican, le daré la reputación que ya ganó.
No creo que esto sea correcto. La viñeta 1+2 sobre la búsqueda de TLB es AFAICT correcta, pero la 3 no lo es. Los paseos por tablas de páginas en x86 (o x86-64) no se manejan en el software (se aplica una excepción, consulte más adelante) sino en el hardware. Es decir, cuando la CPU determina que no puede resolver la dirección usando TLB, recorrerá las tablas de páginas comenzando en la tabla a la que apunta el registro CR3. Solo si esta resolución no tiene éxito, invocará el controlador de errores de página de la CPU. La excepción son las extensiones de virtualización donde en ciertos modos el hipervisor resolverá una falla de página que ocurra en el huésped.
No creo que x86 tenga una forma de hacer actualizaciones de software TLB. Las ISA que permiten el manejo de TLB suave tienen instrucciones especiales para que SW modifique las entradas de TLB, pero no creo que x86 tenga eso, aparte de invlpginvalidar cualquier almacenamiento en caché de TLB para una dirección virtual dada. Si la página de HW no encuentra una entrada para esa dirección virtual, o si los permisos de la entrada no permiten el acceso, obtendrá una #PFexcepción. El sistema operativo maneja eso actualizando la tabla de páginas (posiblemente después de paginar los datos del disco, o haciendo una copia en escritura), y luego reanudar para que la carga/almacenamiento fallida se vuelva a ejecutar y la página HW se realice correctamente.

Tiendo a estar de acuerdo en que esto pertenece a un intercambio de pila de arquitectura de computadora, no a un intercambio de pila de electrónica, pero dado que esto está aquí:

@davidcary tiene razón.

Algo de historia:

Los recorridos de la tabla de páginas Intel x86 NO se almacenaron en caché hasta P5, también conocido como Pentium. Más precisamente, los accesos a la memoria de paseo de la tabla de páginas no se almacenaron en caché, se omitieron el caché. Dado que la mayoría de las máquinas hasta ese momento eran de escritura directa, recibieron valores consistentes con el caché. Pero no fisgonearon los cachés.

P6, también conocido como Pentium Pro, y AFAIK, todos los recorridos de la tabla de páginas de procesadores posteriores pudieron acceder al caché y usar un valor extraído del caché. Por lo tanto, trabajaron con cachés de reescritura. (Por supuesto, podría colocar las tablas de páginas en una memoria no almacenable en caché, definida, por ejemplo, por los MTRR. Pero eso es una gran pérdida de rendimiento, aunque puede ser útil para depurar sistemas operativos).

Por cierto, este "los accesos a la memoria de recorrido de la tabla de páginas pueden acceder a los cachés de datos" es independiente de "las entradas de la tabla de páginas pueden almacenarse (almacenarse en caché) en un búfer de búsqueda de traducción TLB)". En algunas máquinas, la TLB se denomina "caché de traducción".

Otro problema relacionado es que los nodos interiores de las tablas de páginas pueden almacenarse en caché en estructuras de datos aún más similares a TLB, por ejemplo, la memoria caché PDE.

Una diferencia clave: la memoria caché de datos es coherente y espiada. Pero las memorias caché TLB y PDE no están espiadas, es decir, no son coherentes. La conclusión es que, dado que las tablas de páginas pueden almacenarse en caché en cachés TLB y PDE no coherentes, etc., el software debe eliminar explícitamente las entradas individuales o los grupos masivos (como el TLB completo), cuando las entradas de la tabla de páginas que pueden haber sido tan almacenados en caché se modifican. Al menos cuando se cambia de forma "peligrosa", pasando de RW->R->I, o cambiando de dirección.

Creo que es justo decir que cada vez que se agrega un nuevo tipo de almacenamiento en caché similar a TLB no coherente, algún sistema operativo se rompe, porque tenía suposiciones implícitas de que esto no se estaba haciendo.

Una nueva comp. arco. se propuesta comenzó apenas "hace 3 meses". Creo que hubo uno anterior que nunca salió del área 51 (¿no tienes suficientes seguidores?).