Les parcours de table des pages sont-ils mis en cache?

Sur un microprocesseur avec gestion matérielle TLB (disons un Intel x86-64) si un échec TLB se produit et que le processeur parcourt la table des pages, ces accès mémoire (hors puce) passent-ils par la hiérarchie du cache (L1, L2, etc. )?

Oui, pour autant que je sache, sur les processeurs Intel x86-64, lorsqu'un échec TLB se produit et que le processeur parcourt la table des pages, ces accès à la mémoire hors puce passent par la hiérarchie du cache.

Je suis encore un peu flou sur quelques détails, et j'espère qu'une autre réponse les remplira - n'y a-t-il pas un manuel Intel ou AMD qui décrit la marche de la page dans des détails atroces? Ma compréhension est que:

• L'adresse virtuelle dans un registre d'adresses est d'abord transmise à un TLB rapide pour être convertie en une adresse physique - l'adresse dans le PC est transmise au L1 ITLB, l'adresse dans tout autre registre est transférée au L1 DTLB .
• Si cette première recherche échoue, un autre niveau de TLB plus lent et plus grand est tenté. (Ce TLB L2 est-il également divisé en un ITLB et un DTLB, ou s'agit-il d'un cache TLB unifié? Y a-t-il d'autres niveaux TLB - L3? L4?)
• Si la recherche TLB échoue complètement et que le marcheur VHPT x86 et x86-64 est désactivé, le CPU signale une erreur de manque TLB, qui est interceptée par le noyau du système d'exploitation. D'après ce que je comprends, pratiquement tous les processeurs non x86 font la même chose - gérer les erreurs TLB entièrement dans le logiciel. S'ils sont activés, les processeurs x86 et x86-64 ont un marcheur de table VHPT assisté par matériel qui gère les étapes suivantes. (Les puces x86 et x86-64 ont-elles un bit qui désactive entièrement VHPT, ou y a-t-il de nombreux bits qui peuvent activer VHPT pour certaines plages d'adresses et désactiver VHPT pour d'autres plages d'adresses? Où sont situés ces bits?)
• si la recherche TLB échoue complètement, l'adresse virtuelle d'origine (probablement en mode utilisateur) V1 est convertie en V2, l'adresse virtuelle de l'entrée de table de pages PTE qui contient le numéro de page physique pour V1.
• Étant donné que V2 est à nouveau une adresse virtuelle, le processeur passe par la traduction d'adresse virtuelle à physique normale, sauf qu'il saute L1 et va directement à L2.
• Le matériel recherche l'adresse virtuelle V2 dans le TLB en parallèle avec la récupération de ce PTE dans le cache L2 (virtuellement indexé).
• Parce que V2 n'est pas l'adresse d'une instruction, elle ne passe pas par le cache d'instructions L1; et parce que V2 n'est pas l'adresse des données utilisateur normales, elle ne passe pas par le cache de données L1. V2 est introduit initialement dans le cache unifié L2 (une instruction unifiée + données + cache PTE). Voir "l'exemple de hiérarchie de cache" .
• Si le cache L2 (ou L3 ou tout autre cache virtuellement indexé) contient le PTE, le VHPT récupère le PTE de la mémoire cache et installe le PTE pour V1 dans le TLB, et l'adresse physique dans ce PTE est utilisée pour traduire le adresse virtuelle d'origine V1 dans l'adresse RAM physique, récupérant éventuellement ces données ou instructions entièrement dans le matériel sans aucune assistance du système d'exploitation.
• Si tous les niveaux de cache virtuellement indexé échouent, mais que cette deuxième recherche TLB réussit pour V2, alors le VHPT récupère le PTE du cache indexé physiquement ou de la mémoire principale, installe le PTE pour V1 dans le TLB et l'adresse physique dans celui-ci PTE est utilisé pour traduire l'adresse virtuelle d'origine V1 en adresse RAM physique, récupérant éventuellement ces données ou instructions entièrement dans le matériel sans aucune assistance du système d'exploitation.
• Si cette deuxième recherche TLB échoue, le marcheur VHPT matériel abandonne avec un DÉFAUT DE TRADUCTION VHPT.
• Lorsqu'un VHPT TRANSLATION FAULT se produit, le CPU s'interrompt vers le système d'exploitation. L'OS doit comprendre ce qui n'a pas fonctionné et réparer les choses:
• (a) peut-être que la page contenant V2 est actuellement échangée sur le disque, de sorte que le système d'exploitation la lit dans la RAM et redémarre l'instruction qui a échoué, ou
• (b) peut-être qu'un programme buggy essaie de lire ou d'écrire ou d'exécuter un emplacement non valide, et le système d'exploitation met fin au processus, ou
• (c) une variété d'autres astuces que les rédacteurs du système d'exploitation font pour utiliser ce mécanisme pour intercepter divers types d'accès - charger la page contenant V1 qui peut être échangée sur le disque; divers pièges utilisés pour déboguer de nouveaux programmes; pour simuler "W ^ X" sur les processeurs qui ne le prennent pas directement en charge; pour prendre en charge la copie sur écriture; etc.

Le diagramme à la page 2 de Thomas W. Barr, Alan L. Cox, Scott Rixner. "Mise en cache de la traduction: sauter, ne pas marcher (la table des pages)" qui trace une ligne entre "les entrées stockées par le cache MMU" et "les entrées stockées par le cache de données L2". (Cela peut être un document utile pour les personnes qui conçoivent de nouveaux processeurs , qui est totalement sur le thème de la "conception électronique").

Stéphane Eranian et David Mosberger. "Mémoire virtuelle dans le noyau Linux IA-64" et Ulrich Drepper. "Ce que tout programmeur doit savoir sur la mémoire" (cela peut être un document utile pour les personnes qui écrivent des systèmes d'exploitation qui traitent de la table de pages IA-64, ce qui est un peu hors sujet pour ED - peut-être Stack Overflow avec le "fonctionnement-" système " ou la balise " osdev " ou le wiki OSDev.org serait un meilleur endroit pour ce sujet).

Tableau A-10 à la page 533 d'Intel. "Manuel du développeur de logiciels d'architectures Intel® 64 et IA-32" "PAGE_WALKS.CYCLES ... peut indiquer si la plupart des parcours de page sont satisfaits par les caches ou provoquent un échec de cache L2."

J'ai tendance à convenir que cela appartient à un échange de pile d'architecture informatique, pas à un échange de pile électronique, mais puisque c'est ici:

@davidcary est correct.

Un peu d'histoire:

Les parcours de table des pages Intel x86 n'étaient PAS mis en cache jusqu'à P5, alias Pentium. Plus précisément, les accès à la mémoire de marche de la table des pages n'étaient pas mis en cache, contournaient le cache. Étant donné que la plupart des machines jusque-là étaient en écriture, elles ont reçu des valeurs cohérentes avec le cache. Mais ils n'ont pas fouillé les caches.

P6, alias Pentium Pro, et AFAIK, toutes les marches de table de page de processeurs suivantes ont été autorisées à accéder au cache et à utiliser une valeur extraite du cache. Ainsi, ils ont travaillé avec des caches de réécriture. (Vous pouvez bien sûr placer les tables de pages dans une mémoire non mise en cache, définie par exemple par les MTRR. Mais c'est une grosse perte de performances, bien qu'elle puisse être utile pour le débogage de systèmes d'exploitation.)

Soit dit en passant, cet «accès à la mémoire de parcours de table de pages peut accéder aux caches de données» est distinct de «les entrées de table de page peuvent être stockées (mises en cache) dans un tampon TLB Ttranslation Lookaside). Sur certaines machines, le TLB est appelé "Cache de traduction".

Un autre problème connexe est que les nœuds intérieurs des tables de pages peuvent être mis en cache dans des infrastructures de type TLB encore plus, par exemple le cache PDE.

Une différence clé: le cache de données est cohérent et espionné. Mais les caches TLB et PDE ne sont pas espionnés, c'est-à-dire qu'ils ne sont pas cohérents. L'essentiel est que, puisque les tables de pages peuvent être mises en cache dans des TLB non cohérents et des caches PDE, etc., le logiciel doit vider explicitement les entrées individuelles ou les groupes en vrac (comme l'ensemble du TLB), lorsque les entrées de table de pages qui peuvent avoir été ainsi mis en cache sont modifiés. Au moins lorsqu'il est modifié de manière "dangereuse", en passant de RW-> R-> I, ou en changeant d'adresse.

Je pense qu'il est juste de dire que chaque fois qu'un nouveau type de mise en cache non cohérente de type TLB a été ajouté, certains systèmes d'exploitation ont cassé, car ils supposaient implicitement que cela n'était pas fait.