Aujourd'hui, je vais partager un bon article sur TLB. J'espère que chacun solidifiera ses compétences de base et nous permettra de comprendre le système informatique en profondeur.
TLB est l'abréviation de translation lookaside buffer. Tout d'abord, on sait que le rôle de la MMU est de convertir des adresses virtuelles en adresses physiques.
Comment fonctionne la MMU
La relation de mappage entre l'adresse virtuelle et l'adresse physique est stockée dans la table des pages, et maintenant la table des pages est hiérarchique. Les systèmes 64 bits sont généralement de 3 à 5 niveaux. Une configuration courante est une table de pages à 4 niveaux, prenons donc une table de pages à 4 niveaux comme exemple. Il s'agit de tables de pages à quatre niveaux PGD, PUD, PMD et PTE. Il y aura un registre d'adresse de base de table de page sur le matériel, qui stocke la première adresse de la table de page PGD.
Mécanisme de pagination Linux
La MMU recherche tout le chemin depuis la table de pages PGD jusqu'au PTE en fonction du registre d'adresse de base de la table de pages, et trouve finalement l'adresse physique (l'adresse physique est stockée dans la table de pages PTE). C'est comme montrer où se trouve votre maison sur une carte. Afin de trouver votre adresse personnelle, je m'assure d'abord que vous êtes en Chine, puis que vous êtes dans une certaine province, continuez jusqu'à une certaine ville, et enfin trouvez votre maison C'est le même principe. Trouvez-le étape par étape. Vous avez également vu ce processus, il est très lourd. Si je découvre l'emplacement précis de votre domicile pour la première fois, j'écrirai votre nom et votre adresse personnelle. La prochaine fois que vous chercherez, vous n'aurez qu'à me dire quel est votre nom, et je pourrai vous dire l'adresse directement, sans avoir à chercher niveau par niveau.
Le processus de recherche de table de pages à quatre niveaux nécessite quatre accès mémoire. Le retard peut être imaginé, ce qui affecte grandement les performances. Un exemple du processus de recherche de table de pages est illustré dans la figure ci-dessous. Il y aura une chance de développer en détail à l'avenir, apprenez-en simplement ici.
promenade dans la table des pages
Quelle est la nature du TLB
Le TLB est en fait un cache.
Adresse du cache de données (adresse virtuelle ou adresse physique) et données. Le TLB met en cache les adresses virtuelles et leurs adresses physiques mappées. Le TLB recherche le cache en fonction de l'adresse virtuelle. Il n'a d'autre choix que de rechercher en fonction de l'adresse virtuelle.
Le TLB est donc un cache virtuel. Une fois que le TLB existe dans le matériel, le processus de traduction de l'adresse virtuelle à l'adresse physique a changé. L'adresse virtuelle est d'abord envoyée au TLB pour confirmer si elle atteint le cache, et si le cache atteint, l'adresse physique peut être obtenue directement.
Sinon, consultez la table des pages niveau par niveau pour obtenir l'adresse physique. Et mettre en cache la relation de mappage entre l'adresse virtuelle et l'adresse physique dans le TLB. Étant donné que le TLB est un cache virtuel (VIVT), y a-t-il des problèmes d'alias et d'ambiguïté ? Si oui, comment le logiciel et le matériel fonctionnent-ils ensemble pour résoudre ces problèmes ?
Spécial TLB
La plus petite unité d'adresse physique de mappage d'adresse virtuelle est de 4 Ko. Ainsi, le TLB n'a pas réellement besoin de stocker les 12 bits inférieurs de l'adresse virtuelle et de l'adresse physique (car les 12 bits inférieurs sont identiques, il n'est pas du tout nécessaire de les stocker).
De plus, si nous atteignons le cache, nous devons retirer toutes les données du cache en une seule fois. L'adresse virtuelle n'a donc pas besoin du champ offset. Le champ d'index est-il obligatoire ? Cela dépend de la façon dont le cache est organisé.
S'il s'agit d'un cache entièrement associatif. Ensuite, il n'y a pas besoin d'index. Si vous utilisez un cache associé à un ensemble multivoie, un index est toujours requis.
La figure ci-dessous est un exemple d'un TLB associé à un ensemble à quatre voies. La plage d'adressage des processeurs 64 bits d'aujourd'hui n'est pas étendue à 64 bits. L'espace d'adressage 64 bits est très grand, et il n'est pas si grand aujourd'hui.
Par conséquent, afin de simplifier la conception ou de résoudre le coût du matériel, seule une partie des bits d'adresse virtuelle réels sont utilisés. Ici, nous prenons le bus d'adresse 48 bits comme exemple.
Problème de crénelage avec TLB
Permettez-moi de réfléchir d'abord à la première question, à savoir si l'alias existe. Nous savons qu'il n'y a pas de problème d'alias dans le cache de données de PIPT. L'adresse physique est unique, et une adresse physique doit correspondre à une donnée. Mais différentes adresses physiques peuvent stocker les mêmes données.
C'est-à-dire que les données correspondant à l'adresse physique sont une relation un-à-un, et vice versa est une relation plusieurs-à-un. Du fait de la particularité du TLB, la correspondance entre adresses virtuelles et adresses physiques est stockée.
Par conséquent, pour un processus unique, une adresse virtuelle correspond à une adresse physique en même temps, et une adresse physique peut être mappée par plusieurs adresses virtuelles.
En comparant le cache de données PIPT à TLB, nous pouvons savoir qu'il n'y a pas de problème d'alias dans TLB. Cependant, il existe un problème d'alias dans VIVT Cache, car VA doit être converti en PA et les données sont stockées dans PA. Il y a beaucoup d'histoires au milieu, donc certains problèmes ont été introduits.
Problème d'ambiguïté TLB
Nous savons que la plage d'adresses virtuelles observée entre différents processus est la même, donc sous plusieurs processus, la même adresse virtuelle de différents processus peut être mappée à différentes adresses physiques. Cela crée des problèmes d'ambiguïté.
Par exemple, le processus A mappe l'adresse 0x2000 à l'adresse physique 0x4000. Le processus B mappe l'adresse 0x2000 à l'adresse physique 0x5000. Lorsque le processus A s'exécute, mettez en cache la relation de mappage entre 0x2000 et 0x4000 dans TLB. Lorsque le processus B est commuté, le processus B accède aux données à 0x2000 et il récupère les données à partir de l'adresse physique 0x4000 en raison d'un hit TLB.
Cela crée de l'ambiguïté. Comment éliminer cette ambiguïté, nous pouvons apprendre de la méthode de traitement du cache de données VIVT et invalider l'ensemble du TLB lors de la commutation de processus. Aucun des processus commutés n'atteindra le TLB, mais entraînera une perte de performances.
Informations via le train : Itinéraire d'apprentissage de la technologie du code source du noyau Linux + didacticiel vidéo sur le code source du noyau
Apprentissage par le train : code source du noyau Linux réglage de la mémoire gestion des processus du système de fichiers pilote de périphérique/pile de protocole réseau
Comment éviter au maximum le flush TLB
La première chose qui doit être expliquée est que la chasse d'eau ici est comprise comme invalidante. Nous savons que lorsque le processus est commuté, afin d'éviter toute ambiguïté, nous devons vider activement l'ensemble du TLB. Flush TLB peut être évité si nous pouvons distinguer les entrées TLB de différents processus.
Nous savons comment Linux distingue différents processus, et chaque processus a un ID de processus unique. Ce serait formidable si le TLB compare l'ID de processus en plus de la balise pour juger s'il est touché ou non ! De cette manière, les entrées TLB de différents processus peuvent être distinguées.
Bien que le processus A et le processus B aient les mêmes adresses virtuelles, mais que les ID de processus soient différents, le processus B n'atteindra naturellement pas l'entrée TLB du processus A. Par conséquent, le TLB ajoute une correspondance ASID (Address Space ID).
L'ASID est similaire à l'ID de processus, qui est utilisé pour distinguer les entrées TLB de différents processus. De cette manière, il n'est pas nécessaire de vider le TLB lorsque le processus est commuté. Mais un logiciel est toujours nécessaire pour gérer et attribuer les ASID.
Comment gérer les ASID
L'ASID et l'ID de processus ne sont certainement pas les mêmes, ne confondez pas les deux. L'ID de processus peut prendre une large gamme de valeurs. Mais ASID est généralement de 8 ou 16 bits. Ainsi, seuls 256 ou 65536 processus peuvent être distingués. Notre exemple est illustré avec un ASID 8 bits.
Par conséquent, il nous est impossible d'avoir une correspondance un à un entre l'ID de processus et l'ASID. Nous devons attribuer un ASID à chaque processus, et l'ID de processus et l'ASID de chaque processus ne sont généralement pas égaux.
Chaque fois qu'un nouveau processus est créé, un nouvel ASID lui est attribué. Une fois l'ASID alloué, videz tous les TLB et réattribuez l'ASID.
Par conséquent, si vous souhaitez éviter complètement de vider TLB, idéalement, le nombre de processus en cours d'exécution doit être inférieur ou égal à 256. Cependant, ce n'est pas le cas, donc une combinaison de logiciels et de matériel est nécessaire pour gérer les ASID.
Afin de gérer chaque processus, le noyau Linux aura une structure task_struct, où nous pourrons stocker l'ASID attribué au processus en cours. Le registre d'adresse de base de la table des pages a des bits libres qui peuvent également être utilisés pour stocker l'ASID. Lorsque le processus est commuté, l'adresse de base de la table de page et l'ASID (qui peut être obtenu à partir de task_struct) peuvent être stockés ensemble dans le registre d'adresse de base de la table de page.
Lors de la recherche du TLB, le matériel peut comparer l'étiquette et l'ASID pour l'égalité (comparer l'ASID stocké dans le registre d'adresse de base de la table des pages avec l'ASID stocké dans l'entrée TLB). S'ils sont tous égaux, cela signifie que TLB a atteint. Sinon TLB manque. Lorsque le TLB manque, il est nécessaire de parcourir la table des pages en plusieurs niveaux pour trouver l'adresse physique. Ensuite, il est mis en cache dans le TLB et l'ASID actuel est mis en cache en même temps.
partagé par plusieurs processus
Nous savons que l'espace noyau et l'espace utilisateur sont séparés et que l'espace noyau est partagé par tous les processus. Étant donné que l'espace noyau est partagé, lorsque le processus A commute le processus B, si l'adresse à laquelle accède le processus B se trouve dans l'espace noyau, le TLB mis en cache par le processus A peut être utilisé. Mais maintenant, parce que l'ASID est différent, cela conduit à un échec TLB.
Notre mappage global partagé pour l'espace du noyau est appelé mappage global. Les mappages de chaque processus sont appelés mappages non globaux.
Par conséquent, nous introduisons un bit (bit non global (nG)) dans le dernier niveau de la table des pages pour indiquer s'il s'agit d'un mappage global. Lorsque la relation d'adresse physique de mappage d'adresse virtuelle est mise en cache dans le TLB, le bit nG est également stocké.
Lorsque vous jugez s'il faut frapper le TLB, lorsque vous comparez les balises sont égales, alors jugez s'il s'agit d'un mappage global, si c'est le cas, jugez directement le coup TLB sans comparer l'ASID. Lorsqu'il ne s'agit pas d'un mappage global, l'ASID est finalement comparé pour déterminer si le TLB a atteint.
Quand le TLB doit-il être rincé
Venons-en au résumé final, quand faut-il vider TLB.
- Lorsque les ASID sont alloués, tous les TLB doivent être vidés. Les ASID peuvent être gérés à l'aide de bitmaps, et les bitmaps entiers doivent être effacés après le vidage des TLB.
- Lorsque nous créons un mappage de table de page, nous devons vider l'entrée TLB correspondant à l'adresse virtuelle. La première impression peut être que le flush TLB n'est requis que lorsque le mappage de la table de pages est modifié, mais la situation réelle est que le flush TLB est requis tant que le mappage est établi. La raison en est que lorsque vous créez un mappage, vous ne savez pas s'il existe un mappage auparavant. Par exemple, si vous créez un mappage de l'adresse virtuelle A à l'adresse physique B, nous ne savons pas s'il existe un mappage de l'adresse virtuelle A à l'adresse physique C avant, de sorte qu'elle est unifiée dans Flush TLB lors de l'établissement d'une relation de mappage.
Auteur du texte original : [ Learn Embedded Together
