Montgolfière dans l'OS


13

Certains hyperviseurs optimisent l'utilisation de la mémoire à l'aide d'une méthode appelée bulle (du moins c'est ce que KVM l'appelle), cette méthode déduplique la mémoire entre les machines virtuelles et définit les pages communes en lecture seule avec copie en écriture.
C'est en quelque sorte l'opposé d'un appel fork.

Est-il possible d'implémenter au niveau du système d'exploitation pour les processus (je pensais principalement à la duplication de la mémoire lors de la navigation avec Chromium avec plusieurs onglets sur le même site), a-t-il déjà été implémenté?

Réponses:


14

En fait, ce que vous avez décrit confond la montgolfière et la «fusion de la même page». Je vais essayer de développer les deux pour rendre la distinction apparente.

Montgolfière de mémoire

C'est une astuce pour vous assurer qu'une partie de la mémoire allouée à la machine virtuelle invitée reste utilisable par un autre invité ou l' hôte lui-même (caches, etc.). Cela se fait de la manière suivante:

Le noyau invité est injecté avec un pilote, qui surveille l'utilisation de la mémoire de l'invité et `` vole '' une partie de la mémoire inutilisée (en l'allouant pour lui-même dans l'espace mémoire de l'invité, s'assurant ainsi que rien sur cet invité ne peut toucher cette plage).

Ensuite, il informe le noyau hôte, qu'il peut en fait supprimer ces pages mémoire du noyau, qu'elles ne seront pas utilisées dans l'invité (jusqu'à ce que l'invité subisse une certaine pression mémoire, moment auquel le ballon se dégonfle et utilise ces gammes à nouveau).

En fin de compte, le noyau peut allouer exactement la même mémoire à un autre invité et rendre l'utilisation de la mémoire entière beaucoup plus efficace si les invités fonctionnent avec beaucoup de mémoire libre.

Fusion de la même page

Cette technique identifie les pages de mémoire identiques qui, pour une raison quelconque, ne sont pas déjà marquées «quasi-lecture seule» avec copie sur écriture, et les marque comme telles.

Maintenant, au niveau du système d'exploitation, le besoin de ce genre de trucs est limité. Assez simplement, la plupart du temps lorsque vous avez des pages de mémoire identiques, elles sont déjà en lecture seule (parfois même sans CoW), car il s'agit principalement de code d'applications, de bibliothèques, etc. Elles sont ouvertes en mode natif via une carte mémoire, et donc le noyau peut conserver une seule copie d'eux dans le noyau (le cas échéant, il peut également le paginer complètement et lui permettre d'être paginé à partir du magasin principal si nécessaire).

Au niveau du système d'exploitation virtualisé, le même principe est correctement appliqué au sein de chaque sous-système invité. Cependant, le noyau hôte n'a aucune idée si deux des invités exécutent principalement le même code et partagent donc la même mémoire - les invités ne communiquent pas pour coordonner cela.

C'est pourquoi il peut parfois rechercher dans le système entier des pages de mémoire identiques - la plupart du temps, elles seront identiques sur tous les systèmes d'exploitation invités, pas dans chacun d'eux - le noyau invité fait un travail décent en gardant la mémoire propre dans sa plage. Ainsi, dans l'environnement VM typique, où un noyau hôte gère plus de 50 invités, les économies de mémoire peuvent être assez substantielles.

Les deux à la fois

La montgolfière et la fusion de pages identiques peuvent très bien coexister, réalisant une surcharge de mémoire assez importante pour des systèmes identiques.


Pour répondre à votre question, la fusion de pages identiques peut et parfois est activée au niveau du système d'exploitation. Cela a à voir avec le partage de page qui est interprété, et pourrait donc finir par être identique sans avoir le même fichier de sauvegarde.

Dans votre exemple Chromium - les fichiers binaires de processus eux-mêmes sont déjà dédupliqués via une carte de démarrage en lecture seule - ils partagent exactement le même espace mémoire. Les caches de page (contenu des onglets) sont généralement également partagés entre les processus (copie en écriture seule) en raison de la façon dont le cache disque est géré - le même fichier sur le disque peut être ouvert simultanément entre différents processus dans la machine virtuelle -un sens optimal.

L'avantage serait plus évident avec l'état partagé de différents moteurs Javascript - mais je ne suis pas sûr s'ils sont alloués dans la même disposition de mémoire exacte, garantissant que la page de mémoire entière est identique.

C'est différent sur les systèmes mobiles. Android, par exemple, utilise largement KSM pour dédupliquer un code identique entre différentes applications.

Dans les deux cas, vous pouvez l'activer vous-même sous Linux (Kernel SamePage Merging). Le pilote exporte diverses statistiques que, après avoir lu cette réponse, vous devriez être en mesure d'interpréter et de décider vous-même si cela correspond bien à votre objectif.

https://www.kernel.org/doc/Documentation/vm/ksm.txt


3
La fusion d'une même page est également appelée «mémoire transcendante», selon l'hyperviseur (et son âge).
Tim Post

Merci, je vois que KSM nécessite que l'application en soit consciente, et à partir d'une recherche (rapide), Chromium ne le prend pas en charge pour l'instant. Je suis conscient que les binaires sont dédupliqués, mais je fais principalement référence à la sortie JIT et aux scripts bruts qui mettent une lourde charge sur ma RAM ...

Les scripts bruts dans Chromium sont également dédupliqués - ils atterrissent dans le cache disque comme avec tous les autres objets Web, et le cache disque est mappé, pas lu.
qdot

Les scripts bruts sont mappés, mais même les scripts courants (comme jQuery et Angular.js) sont répliqués dans le cache et ils ne sont pas mis en correspondance les uns avec les autres car il y a une utilisation intensive des CDN et des répliques exactes des fichiers de script sur les différents serveurs de site.

Cela devrait probablement se retrouver dans le chat, mais j'aimerais voir vos statistiques du KSM de Linux.
qdot
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.