Roman Gushchin (un ingénieur logiciel Facebook) enregistrement dans la liste de développement du noyau Linux, un ensemble de correctifs pour l'application de mappage de mémoire du contrôleur de dalle (un contrôleur de mémoire).
Le nouveau contrôleur est remarquable en déplaçant la comptabilité de dalle du niveau de la page mémoire au niveau de l'objet du noyau, ce qui permet de partager des pages de dalle entre différents groupes c, plutôt que d'allouer des caches de dalle séparés pour chaque groupe c.
Roman a trouvé ce qu'il appelle une «faille très grave» dans le contrôleur de mémoire de la dalle existant qui conduit à une faible utilisation de nos jours avec les groupes de contrôle.
«La vraie raison pour laquelle la mise en page existante conduit à une faible utilisation de la dalle est simple: les pages de la dalle sont utilisées exclusivement par un pool de mémoire.
S'il n'y a que quelques allocations d'une certaine taille effectuées par un groupe de contrôle, ou s'il reste des objets actifs après la suppression du groupe de contrôle, ou si le groupe de contrôle contient une seule application threadée qui alloue à peine des objets du noyau, mais à chaque fois sur un nouveau processeur: dans tous ces cas, l'utilisation de la dalle qui en résulte est très faible.
Si la comptabilité kmem est désactivée, le noyau peut utiliser l'espace libre sur les pages de dalle pour d'autres allocations. «
Le contrôleur de mémoire Slab proposé par Romano Gushchin l'année dernière était assez prometteur car augmente l'efficacité de l'utilisation de la dalle, réduire la taille de la mémoire utilisée pour la dalle de 30 à 45% et réduisent considérablement la consommation totale de mémoire du noyau.
En outre, les patchs implémentés ont indiqué que Facebook utilise déjà le code en production sur ses serveurs et était économie d'environ 650 à 700 Mo + pour les serveurs Web frontaux, la mise en cache de bases de données et les serveurs DNS, entre autres récompenses.
En réduisant le nombre de dalles non mobiles, un effet positif est également observé dans le domaine de la réduction de la fragmentation de la mémoire. Le nouveau contrôleur de mémoire simplifie considérablement le code pour la dalle comptable et ne nécessite pas d'algorithmes compliqués pour la création dynamique et la suppression des caches de dalles pour chaque groupe c.
Tous les cgroups de mémoire dans la nouvelle implémentation utilisent un ensemble commun de caches de dalle, et la durée de vie des caches de dalle n'est plus liée à la durée de vie des contraintes de mémoire définies via cgroup.
La comptabilité des ressources plus précise mise en œuvre dans le nouveau contrôleur de dalle devrait théoriquement charger davantage le processeur, mais en pratique, les différences se sont avérées négligeables.
En particulier, le nouveau pilote de dalle est utilisé depuis plusieurs mois sur les serveurs Facebook en fonctionnement qui traitent différents types de charges, et jusqu'à présent aucune régression significative n'a été détectée.
Le patch contient quelques parties semi-indépendantes, qui peuvent également trouver leur utilisation en dehors du contrôleur mémoire de la dalle:
- L'API de chargement de sous-page, qui peut être utilisée à l'avenir pour compter d'autres objets qui ne sont pas de la taille d'une page, par exemple les allocations percpu
- L'API mem_cgroup_ptr, où les pointeurs comptés vers un memcg, peut être réutilisée pour une reparentation efficace d'autres objets, par exemple pagecache.
En même temps, il y a une diminution significative de la consommation de mémoire- Sur certains hôtes, il était possible d'économiser jusqu'à 1 Go de mémoire, mais cet indicateur dépend largement de la nature de la charge, la taille totale de la RAM, la quantité de CPU et les caractéristiques du travail avec la mémoire.
Au lieu de créer un ensemble distinct de kmem_caches pour chaque groupe de contrôle de mémoire, deux ensembles globaux sont utilisés: l'ensemble racine pour les affectations de groupe de contrôle non comptabilisées et de groupe racine et le second ensemble pour toutes les autres affectations. Cela permet de simplifier la gestion de la durée de vie des kmem_caches individuels.
Enfin, si vous souhaitez connaître le nouvel ensemble de 19 correctifs, vous pouvez le trouver dans la liste courrier du noyau.