La MMU accède à un tableau qui décrit comment traduire les adresses virtuelles en adresses physiques. (Il n'est pas nécessaire de traduire les adresses physiques en adresses virtuelles, et cela serait en général impossible car la même adresse physique peut être accessible via plusieurs adresses virtuelles ou peut être non mappée.) La disposition de cette table dépend de l'architecture du processeur, mais le principe général est toujours le même :il y a un registre CPU qui contient l'adresse physique d'une table, qui contient les adresses physiques d'autres tables, et ainsi de suite (pour 2 à 4 niveaux au total sur les architectures existantes) jusqu'à un niveau de tables qui contient les adresses physiques où se trouvent les données. À chaque niveau, l'élément de la table à utiliser est déterminé par certains des bits de l'adresse virtuelle.
La MMU ne connaît pas les processus du système d'exploitation en tant que tels. Lorsque le CPU passe à l'exécution d'un processus différent, c'est-à-dire lorsqu'un changement de contexte se produit, c'est le travail du code de changement de contexte du système d'exploitation de mettre à jour les tables MMU si nécessaire. En pratique, je pense que tous les systèmes Unix conservent une copie des tables en mémoire pour chaque processus et mettent simplement à jour le registre MMU pour pointer vers la table de niveau supérieur du processus en cours.
Il y a en fait une partie de la MMU qui se soucie des processus du système d'exploitation :le TLB. La recherche d'entrées dans la table MMU est assez coûteuse car elle implique plusieurs accès mémoire. Le TLB est un cache de ces recherches. Lors d'un changement de contexte, le système d'exploitation doit invalider le TLB (c'est-à-dire supprimer toutes les entrées du cache), car le mappage sera différent pour le nouveau processus. De nombreuses architectures permettent au système d'exploitation de placer un indicateur dans chaque entrée de la table MMU pour dire "cette entrée appartient au processus N". Une entrée TLB est alors ignorée si le numéro de processus qu'elle contient n'est pas le numéro de processus actuel. Un registre CPU contient le numéro de processus actuel et le code de changement de contexte le met à jour. Ce mécanisme signifie que le TLB peut contenir des informations sur plusieurs processus à la fois, ce qui améliore les performances lors du basculement entre ces processus. Parce qu'il y a souvent moins de bits disponibles pour stocker N que nécessaire pour stocker tous les ID de processus du système d'exploitation, N n'est pas l'ID de processus, mais un nombre généré par le système d'exploitation à cette fin et qui change avec le temps, s'il est utilisé.
Sous Linux, le noyau maintient une table de pages à trois niveaux (indépendamment des capacités du processeur). Le niveau supérieur est le répertoire global de la page, et chaque processus a son propre répertoire, pgd en mm_struct . Ainsi, chaque processus peut avoir ses propres mappages, donc l'adresse 12345 dans différents processus pointe vers différentes adresses physiques.
Les processeurs ne sont pas vraiment conscients des processus, mais ils ont tendance à avoir des fonctionnalités pour les prendre en charge. Sur les processeurs de style x86, il existe diverses fonctionnalités liées aux tâches, mais elles ont en fait tendance à être ignorées. Étant donné que la planification des processus est gérée par le noyau, il peut suivre lui-même les modifications de la table des pages et mettre à jour l'état du processeur requis pour basculer vers la table des pages d'un nouveau processus lorsqu'il change de tâche. Sur les PC x86, cela implique de mettre à jour le registre de contrôle CR3 qui pointe vers le répertoire des pages.
Le chapitre sur la gestion des tables de pages dans Comprendre le gestionnaire de mémoire virtuelle Linux de Mel Gorman livre donne un bon aperçu.