Le gestionnaire de mémoire est un sous-ensemble du système d’exploitation qui partage la mémoire entre l’OS et les diverses applications. Le terme mémoire fait surtout référence la mémoire principale (=RAM), mais sa gestion demande la contribution de la mémoire auxiliaire et de la mémoire cache. Le gestionnaire de mémoire est notamment chargé d’allouer efficacement la mémoire aux processus, ce qui implique qu’il doit être capable de répertorier les emplacements libres de la mémoire disponible, d’allouer la mémoire nécessaire aux nouveaux processus et de récupérer la mémoire des processus qui se terminent. L’allocateur de processus à l’intérieur du noyau Linux est le SLAB allocator (ou SLAB tout simplement).SLAB repose sur un système de blocs et de cache qui permet d’optimiser les demandes de mémoire. Ce type de gestion de la mémoire réduit la fragmentation causée par les opérations d’allocation et de délocalisation. L’allocation de blocs implique la mise en œuvre d’un cache pour un certain type/taille d’objet qui dispose d’un certain nombre de blocs de mémoire pré-allouées découpés en morceaux de taille fixe qui conviennent à des objets spécifiques. SLAB gère les morceaux de sorte que, lorsque le kernel est sollicité pour l’allocation de mémoire à un objet, il peut satisfaire cette demande avec un morceau libre d’un bloc existant. SLAB conserve la mémoire allouée en vue d’une réutilisation, lors d’affectations ultérieures d’objets similaires, et permet ainsi de réduire les frais généraux qui sont liés à l’initialisation de l’objet.
Roman Gushchin, un membre de l’équipe d’ingénierie du noyau Linux chez Facebook, a découvert ce qu’il considère comme un « ;défaut grave ;» dans le contrôleur/gestionnaire de mémoire actuel. Et il a récemment proposé un nouveau contrôleur de mémoire de blocs qui promet de considérablement améliorer l’utilisation de la mémoire entre plusieurs « ;cgroups (ou control groups) ;» de mémoire en partageant des slab pages. Précisons que les cgroups renvoient à une fonctionnalité du noyau Linux qui permet de limiter, compter et isoler l’utilisation des ressources d’un système (processeur, mémoire, utilisation disque, etc.) et le terme « ;slab page ;» pourrait être assimilé au processus d’allocation de mémoire par SLAB.
D’après Gushchin, « ;la véritable raison pour laquelle la conception existante conduit à un faible usage de SLAB est simple : les slab pages sont exclusivement utilisés par un seul cgroup de mémoire. S’il n’y a seulement quelques affectations d’une certaine taille effectuées par un cgroup ou si certains objets actifs sont laissés après que le cgroup ait été supprimé ou alors si le cgroup contient une application à thread unique qui n’alloue pratiquement aucun objet du noyau, mais le fait à chaque fois sur un nouveau CPU : dans tous ces cas, l’usage de SLAB qui en résulte est très faible. Si le calcul des kmem est désactivé, le noyau est capable d’utiliser l’espace libre sur les slab pages pour d’autres allocations ;».
Gushchin soutient que ce n’était pas un problème lorsque le contrôleur kmem a été introduit en tant que fonction opt-in qui devait être activée pour chaque cgroup mémoire. Maintenant, cependant, le contrôleur kmem est activé par défaut pour cgroup v1 et v2. Et comme les systèmes modernes ont tendance à créer un très grand nombre de cgroups, l’utilisation de SLAB est moins efficace. Selon lui, en partageant les slab pages entre plusieurs cgroups de mémoire et en utilisant un système remanié où la comptabilité est effectuée par objet plutôt que par page, on disposerait sur le noyau Linux d’un contrôleur de mémoire optimisé offrant un niveau d’utilisation beaucoup plus efficace.
Le patch proposé par Gushchin contient deux éléments semi-indépendants : une API de chargement de sous-page pouvant être utilisée à l’avenir pour les besoins de comptabilité et une API mem_cgroup_ptr. Les tests effectués avec le nouveau contrôleur de mémoire proposé par Gushchin ont montré qu’il est possible de gagner entre 35 et 42 % de mémoire en plus sous Linux au niveau du Front-end Web, du cache de base de données, du serveur DNS et sur de nombreuses autres charges de travail. La proposition de Gushchin est actuellement sous le flag « ;request for comments ;». Si elle est acceptée, elle pourrait être intégrée dans la version du noyau Linux dès 2020.
Source : LKML
Et vous ?
Qu’en pensez-vous ?Voir aussi
Si Linux a de la peine à s'imposer sur le desktop c'est à cause de la fragmentation de l'écosystème, d'après Linus Torvalds Google découvre des centaines de situations de compétition dans le noyau Linux en se servant de KCSAN, son nouveau détecteur de courses critiques pour le noyau Linux Des vulnérabilités de corruption de mémoire dans systemd affectent la plupart des distributions Linux. Aucun correctif n'est disponible pour le moment 
