Calculer Girl
  1. Calculer Girl
  3. Gestion des tables de pages Linux et MMU
Intereting Posts
Puis-je utiliser epoll avec déclenchement non bloquant? Reverse engineering d’applications natives en interceptant le trafic réseau avec Charles 4? Comment tuer doucement rsync? Est-il possible de déconnecter un client http de PHP? C ++ sous Linux ne reconnaissant pas les commandes comme exit () et printf () Comment puis-je faire face aux incompatibilités 32 bits / 64 bits lors de l’exécution d’IPC via SendMessage? Obtenir l’interpréteur de ligne de commande Comment utiliser la flèche vers le haut dans le script shell pour obtenir la commande précédente Ecrire directement sur stdout de différents processus Méthode basée sur CL pour l’ajout de serveurs HTTP sur le système IBMi Comment partager un verrou mutex pour un groupe de pthreads? Comment fonctionne la récursion htaccess? Nginx interdisant l’exécution de PHP dans le répertoire des téléchargements avec Magento nginx pas commencé et ne peut pas démarrer Récupère le chemin réseau du lecteur monté, des fenêtres

Gestion des tables de pages Linux et MMU

J’ai une question sur la relation entre le kernel Linux et MMU. J’ai maintenant compris que le kernel Linux gère la table de pages entre les adresses de mémoire virtuelle et les adresses de mémoire physique. Dans le même temps, il existe une architecture MMU dans x86 qui gère la table de pages entre les adresses de mémoire virtuelle et les adresses de mémoire physique. Si le MMU présente près de CPU, le kernel doit-il toujours prendre en charge la table de pages?

Cette question peut être stupide, mais l’autre question est de savoir si MMU prend soin de l’espace mémoire, qui gère une mémoire élevée et une mémoire insuffisante? Je crois que le kernel recevra la taille de la mémoire virtuelle du MMU (4 Go en 32 bits), puis le kernel fera la distinction entre l’espace utilisateur et l’espace du kernel dans l’adresse virtuelle. Ai-je raison? ou complètement faux?

Merci beaucoup d’avance!

Les responsabilités de gestion des pages du système d’exploitation et du MMU sont deux aspects d’un même mécanisme, qui se situe à la frontière entre l’architecture et la micro-architecture.

La première partie définit le «contrat» entre le matériel et le logiciel qui s’exécute dessus (dans ce cas, le système d’exploitation). Si vous souhaitez utiliser la mémoire virtuelle, vous devez créer et gérer une table de pages comme décrit dans ce contrat. Le côté MMU, quant à lui, est une unité matérielle chargée d’effectuer les tâches matérielles de la traduction d’adresse. Cela peut inclure ou non des optimisations matérielles, celles-ci sont généralement masquées et peuvent être implémentées de différentes manières pour fonctionner sous le capot, du moment qu’elles conservent le côté matériel du contrat.

En théorie, la MMU peut décider d’établir un ensemble d’access à la mémoire pour chaque traduction (un parcours de page), afin d’obtenir le comportement requirejs. Cependant, comme il s’agit d’un élément essentiel à la performance, la plupart des MMU optimisent ce résultat en mettant en cache les résultats des passages de pages précédents dans le TLB, tout comme un cache stocke les résultats des access précédents. les access à la table de pages car elle réside généralement dans la mémoire cache). La MMU peut gérer plusieurs TLB (la plupart des implémentations séparent celles pour les pages de données et de code et certaines ont des TLB de second niveau), et fournissent la traduction sans que vous ne remarquiez cela, sauf pour le temps d’access plus rapide.

Il convient également de noter que le matériel doit se prémunir contre de nombreux cas en coin susceptibles de nuire à la cohérence de ces “mises en cache” de TLB de traductions précédentes, par exemple un aliasing de pages ou des remappages en cours d’utilisation. Sur certaines machines, les cas les plus dangereux nécessitent même un stream de chasse massif appelé abattage TLB.