Romano Gushchin (ingénieur logiciel chez Facebook) a enregistré un ensemble de correctifs pour l'application d'allocation de mémoire du pilote slab (un contrôleur de mémoire) sur la liste de diffusion de développement du noyau Linux.
Le nouveau pilote se distingue par le déplacement de la comptabilisation des blocs du niveau des pages mémoire au niveau des objets du noyau, ce qui permet de partager les pages de blocs entre différents groupes C, au lieu d'allouer des caches de blocs distincts 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 très prometteur car il permet une efficacité accrue dans l'utilisation des Slab, réduit la taille de la mémoire utilisée pour les Slab de 30 à 45 % et réduit considérablement la consommation totale de mémoire du cœur.
De plus, les correctifs mis en œuvre ont indiqué que Facebook utilise déjà le code en production sur ses serveurs et économise entre 650 et 700 Mo pour les serveurs Web frontaux , la mise en cache de la base de données et les serveurs DNS, entre autres avantages.
La réduction du nombre de blocs non déplaçables a également un effet positif sur la fragmentation de la mémoire. Le nouveau contrôleur de mémoire simplifie considérablement le code de gestion des blocs et élimine le besoin d'algorithmes complexes pour la création et la suppression dynamiques des caches de blocs 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 contrôleur de dalle a été utilisé pendant plusieurs mois sur des serveurs Facebook en production gérant 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.
Dans le même temps, on observe une diminution significative de la consommation de mémoire : sur certains hôtes, il a été possible d'économiser jusqu'à 1 Go de mémoire, mais cet indicateur dépend largement de la nature de la charge, de la taille totale de la RAM, de la quantité de CPU et des caractéristiques de 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 en savoir plus sur le nouvel ensemble de 19 correctifs, vous pouvez le trouver sur la liste de diffusion du noyau.