Comment le kernel Linux gère-t-il moins de 1 Go de mémoire physique?

Toutes les adresses virtuelles (linéaires) ne doivent pas être associées à quoi que ce soit. Si le code accède à la page non mappée, le défaut de page est augmenté.

La page physique peut être associée à plusieurs adresses virtuelles simultanément.

Dans la mémoire virtuelle de 4 Go, il y a 2 sections: 0x0 … 0xbfffffff – est la mémoire virtuelle du processus et 0xc0000000 .. 0xffffffff est une mémoire virtuelle du kernel.

• Comment le kernel peut-il mapper 896 Mo à partir de seulement 512 Mo?

Il cartographie jusqu’à 896 Mo. Donc, si vous n’avez que 512, il n’y aura que 512 Mo mappés.

Si votre mémoire physique est en 0x00000000 à 0x20000000, elle sera mappée pour un access direct au kernel aux adresses virtuelles 0xC0000000 à 0xE0000000 (mappage linéaire).

• Qu’en est-il des processus en mode utilisateur dans cette situation?

La mémoire physique pour les processus utilisateur sera mappée (pas un mappage page à page séquentiel mais plutôt aléatoire) aux adresses virtuelles 0x0 …. 0xc0000000. Ce mappage sera le second mappage pour les pages à partir de 0,896 Mo. Les pages seront extraites de listes de pages gratuites.

• Où sont les processus en mode utilisateur dans la mémoire physique?

Nulle part.

• Chaque article explique uniquement la situation, lorsque vous avez installé 4 Go de mémoire et le

Chaque article explique comment 4 Go d’espace d’adressage virtuel sont mappés. La taille de la mémoire virtuelle est toujours de 4 Go (pour les machines 32 bits sans extensions de mémoire telles que PAE / PSE / etc pour x86)

Comme indiqué en 8.1.3. Memory Zones 8.1.3. Memory Zones de 8.1.3. Memory Zones du livre Linux Kernel Development par Robert Love (j’utilise la troisième édition), il existe plusieurs zones de mémoire physique:

• ZONE_DMA – Contient des frameworks de page de mémoire inférieurs à 16 Mo
• ZONE_NORMAL – Contient des frameworks de page de mémoire supérieurs ou égaux à 16 Mo et inférieurs à 896 Mo
• ZONE_HIGHMEM – Contient des frameworks de page de mémoire à 896 Mo ou plus

Donc, si vous avez 512 Mo, votre ZONE_HIGHMEM sera vide et ZONE_NORMAL aura 496 Mo de mémoire physique mappée.

Aussi, jetez un oeil à 2.5.5.2. Final kernel Page Table when RAM size is less than 896 MB 2.5.5.2. Final kernel Page Table when RAM size is less than 896 MB section de 2.5.5.2. Final kernel Page Table when RAM size is less than 896 MB du livre. Il s’agit de cas où vous avez moins de mémoire que 896 Mo.

En outre, pour ARM, il existe une description de la disposition de la mémoire virtuelle: http://www.mjmwired.net/kernel/Documentation/arm/memory.txt

La ligne 63 PAGE_OFFSET high_memory-1 est la partie mappée directe de la mémoire

Le matériel fournit une unité de gestion de la mémoire . C’est un circuit capable d’intercepter et de modifier tout access à la mémoire. Chaque fois que le processeur accède à la RAM, par exemple pour lire l’instruction suivante à exécuter ou comme un access aux données déclenché par une instruction, il le fait à une adresse qui est, en gros, une valeur de 32 bits. Un mot de 32 bits peut avoir un peu plus de 4 milliards de valeurs distinctes, il y a donc un espace d’adressage de 4 Go: c’est le nombre d’octets pouvant avoir une adresse unique.

Donc, le processeur envoie la requête à son sous-système de mémoire, comme “chercher l’octet à l’adresse x et me le rendre”. La demande passe par la MMU, qui décide quoi faire avec la demande. La MMU divise virtuellement l’espace de 4 Go en pages ; La taille de la page dépend du matériel que vous utilisez, mais les tailles habituelles sont de 4 et 8 Ko. Le MMU utilise des tables qui lui indiquent ce qu’il faut faire avec les access pour chaque page: soit l’access est accordé avec une adresse réécrite (l’entrée de la page indique: “oui, la page contenant l’adresse x existe, elle est dans la RAM physique à l’adresse y “) ) ou rejeté, à quel point le kernel est appelé pour gérer les choses plus loin. Le kernel peut décider de supprimer le processus incriminé ou de travailler et de modifier les tables MMU afin que l’access puisse être réessayé, cette fois avec succès.

C’est la base de la mémoire virtuelle : du sharepoint vue du processus, le processus a un peu de RAM, mais le kernel l’a déplacé sur le disque dur, dans “swap space”. Le tableau correspondant est marqué comme “absent” dans les tables MMU. Lorsque le processus accède à ses données, la MMU appelle le kernel, qui récupère les données du swap, les place dans un espace libre de la RAM physique et modifie les tables MMU pour qu’elles pointent vers cet espace. Le kernel retourne alors au code du processus, directement à l’instruction qui a déclenché le tout. Le code de processus ne voit rien de l’ensemble de l’entreprise, sauf que l’access à la mémoire a pris un certain temps.

La MMU gère également les droits d’access, ce qui empêche un processus de lire ou d’écrire des données appartenant à d’autres processus ou au kernel. Chaque processus a son propre ensemble de tables MMU, et le kernel gère ces tables. Ainsi, chaque processus a son propre espace d’adresse, comme s’il était seul sur une machine avec 4 Go de RAM – sauf que le processus aurait intérêt à ne pas accéder à la mémoire qu’il n’allait pas correctement du kernel car les pages correspondantes sont marquées comme absent ou interdit.

Lorsque le kernel est appelé via un appel système provenant d’un processus, le code du kernel doit s’exécuter dans l’espace adresse du processus. le code du kernel doit donc se trouver quelque part dans l’espace d’adressage de chaque processus (mais protégé: les tables MMU empêchent l’access à la mémoire du kernel à partir du code utilisateur non privilégié). Comme le code peut contenir des adresses codées en dur, le kernel devrait être à la même adresse pour tous les processus. conventionnellement, sous Linux, cette adresse est 0xC0000000. Les tables MMU pour chaque processus mappent cette partie de l’espace d’adressage à tous les blocs de RAM physiques que le kernel était réellement chargé au démarrage. Notez que la mémoire du kernel n’est jamais remplacée (si le code capable de lire les données de l’espace d’échange était lui-même interverti, les choses tourneraient rapidement au vinaigre).

Sur un PC, les choses peuvent être un peu plus compliquées, car il existe des modes 32 bits et 64 bits, ainsi que des registres de segment et PAE (qui agissent comme une sorte de MMU de second niveau avec des pages volumineuses). Le concept de base rest le même: chaque processus a sa propre vue sur un espace d’adressage virtuel de 4 Go, et le kernel utilise le MMU pour mapper chaque page virtuelle sur une position physique appropriée dans la RAM, ou nulle part.

osgx a une excellente réponse, mais je vois un commentaire où quelqu’un ne comprend toujours pas.

Chaque article explique uniquement la situation, lorsque vous avez installé 4 Go de mémoire et que le kernel mappe le 1 Go dans l’espace kernel et que les processus utilisateur utilisent la quantité de RAM restante.

Voici une grande partie de la confusion. Il y a de la mémoire virtuelle et de la mémoire physique . Chaque processeur 32 bits dispose de 4 Go de mémoire virtuelle . La séparation traditionnelle du kernel Linux était 3G / 1G pour la mémoire utilisateur et la mémoire du kernel, mais les nouvelles options permettent un partitionnement différent.

Pourquoi faire la distinction entre le kernel et l’espace utilisateur? – ma propre question

Lorsqu’une tâche change, le MMU doit être mis à jour. L’espace MMU du kernel devrait restr le même pour tous les processus. Le kernel doit gérer les interruptions et les demandes de pannes à tout moment.

Comment fonctionne la cartographie virtuelle / physique? – ma propre question.

Il existe de nombreuses permutations de mémoire virtuelle.

• un seul mappage privé vers une page RAM physique.
• un mappage virtuel en double sur une seule page physique.
• un mappage qui émet une erreur SIGBUS ou autre.
• un mappage sauvegardé par disque / swap.

Dans la liste ci-dessus, il est facile de voir pourquoi vous pouvez avoir plus d’espace d’adressage virtuel que la mémoire physique. En fait, le gestionnaire de pannes inspecte généralement les informations de la mémoire de processus pour voir si une page est mappée (je veux dire allouée pour le processus), mais pas en mémoire . Dans ce cas, le gestionnaire de pannes appellera le sous-système d’E / S à lire dans la page. Lorsque la page a été lue et que les tables MMU ont été mises à jour pour pointer l’adresse virtuelle vers une nouvelle adresse physique, le processus à l’origine de la panne reprend.

Si vous comprenez ce qui précède, vous comprendrez pourquoi vous souhaitez un mappage virtuel plus important que la mémoire physique. C’est la manière dont l’échange de mémoire est pris en charge.

Il y a d’autres utilisations. Par exemple, deux processus peuvent utiliser la même bibliothèque de code. Il est possible qu’ils se trouvent à des adresses virtuelles différentes dans l’espace de processus en raison de la liaison. Dans ce cas, vous pouvez mapper les différentes adresses virtuelles sur la même page physique afin d’économiser de la mémoire physique. C’est assez courant pour les nouvelles allocations; ils pointent tous vers une «page zéro» physique. Lorsque vous touchez / écrivez la mémoire, la page zéro est copiée et une nouvelle page physique est affectée (COW ou copie sur écriture).

Il est également parfois utile de créer un alias avec les pages virtuelles, l’une en cache et l’autre non en cache . Les deux pages peuvent être examinées pour voir quelles données sont mises en cache et ce qui ne l’est pas.

Principalement virtuel et physique ne sont pas les mêmes! Facilement énoncé, mais souvent déroutant lorsque l’on regarde le code VMM Linux.

–

Bonjour, en fait, je ne travaille pas sur la plate-forme matérielle x86, il peut donc y avoir des erreurs techniques dans mon article.

A ma connaissance, la plage comprise entre 0 ou 16 Mo – est spécifiée, alors que vous avez plus de RAM que ce nombre, par exemple, vous avez 1 Go de RAM physique sur votre carte, appelée “mémoire faible”. Si vous avez plus de RAM physique que 896 Mo sur votre carte, le rest de la RAM physique est appelé highmem.

En parlant de votre question, il y a 512 Mo de RAM physique sur votre carte, alors en fait, il n’y a pas de 896, pas de highmem.

Le kernel de RAM total peut voir et peut également cartographier 512 Mo.

Parce qu’il existe un mappage 1 vers 1 entre la mémoire physique et l’adresse virtuelle du kernel, il existe donc un espace d’adressage virtuel de 512 Mo pour le kernel. Je ne suis vraiment pas sûr que la phrase précédente soit correcte ou non, mais c’est ce que je pense.

Ce que je veux dire, c’est que s’il y a 512 Mo, la quantité de RAM physique que le kernel peut gérer est également de 512 Mo, de plus, le kernel ne peut pas créer un tel espace d’adressage de plus de 512 Mo.

Reportez-vous à l’espace utilisateur, il y a un point différent, les pages de l’application de l’utilisateur peuvent être transférées sur le disque dur, mais les pages du kernel ne le peuvent pas.

Donc, pour l’espace utilisateur, avec l’aide de tables de pages et d’autres modules connexes, il semble qu’il y ait encore 4 Go d’espace d’adresse. Bien sûr, il s’agit d’un espace d’adresse virtuel et non d’un espace physique RAM.

C’est ce que je comprends.

Merci.

Si la mémoire physique est inférieure à 896 Mo, le kernel linux correspond à cette adresse physique.

Pour plus de détails, voir ceci. http://learnlinuxconcepts.blogspot.in/2014/02/linux-addressing.html