Le gestionnaire de mémoire est un sous-ensemble du système d'exploitation Il partage la mémoire entre le système d'exploitation et les différentes applications. Le terme mémoire se réfère principalement à la mémoire principale (RAM), mais sa gestion nécessite l'apport de mémoire auxiliaire et de mémoire cache.
Le gestionnaire de mémoire est particulièrement responsable de l'allocation efficace de la mémoire aux processus, ce qui signifie que vous devez être en mesure de répertorier les emplacements libres de mémoire disponible, d'allouer la mémoire requise pour les nouveaux processus et de récupérer la mémoire des processus qui se terminent. Le répartiteur de processus dans le noyau Linux est le répartiteur SLAB.
DALLE s'appuie sur un système de blocs et de cache qui optimise 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 relocalisation.
L'allocation de blocs implique l'implémentation d'un cache pour un certain type / taille d'objet qui a plusieurs blocs de mémoire pré-alloués coupés en morceaux de taille fixe qui conviennent à des objets spécifiques.
SLAB gère les pièces de sorte que lorsque le noyau est invité à allouer de la mémoire à un objet, Vous pouvez satisfaire cette demande avec une pièce de rechange d'un bloc existant. SLAB conserve la mémoire allouée pour la réutilisation, lors des allocations ultérieures d'objets similaires, et réduit ainsi les frais généraux liés à l'initialisation des objets.
Ils ont l'intention de remplacer SLAB
Romain Gushchin, Membre de l'équipe d'ingénierie du noyau Linux de Facebook, il a découvert ce qu'il considère comme une «faille grave» dans le gestionnaire / contrôleur de mémoire actuel. Et ra récemment proposé un nouveau contrôleur de mémoire bloquer qui promet d'améliorer considérablement l'utilisation de la mémoire entre plusieurs «groupes de contrôle» (ou groupes de contrôle) de la mémoire.
Compte tenu de cela, il est important de noter que cgroups fait référence à une fonctionnalité du noyau Linux qui permet de limiter, compter et isoler l'utilisation des ressources d'un système (processeur, mémoire, utilisation du disque, etc.) et le terme «page de slab» pourrait être assimilé au processus d'allocation de mémoire par SLAB.
Selon Gushchin:
«La vraie raison pour laquelle la conception existante conduit à une faible utilisation de SLAB est simple: les pages Slab sont utilisées exclusivement par un seul pool de mémoire.
S'il n'y a que quelques allocations d'une certaine taille faites 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 n'alloue pratiquement aucun noyau, mais le fait à chaque fois dans un nouveau processeur: dans tous ces cas, l'utilisation du SLAB qui en résulte est très faible.
Si le calcul kmem est désactivé, le noyau peut utiliser l'espace libre sur les pages de tuiles pour d'autres allocations «.
Gushchin soutient que ce n'était pas un problème lorsque le pilote kmem a été introduit en tant que fonctionnalité facultative qui devait être activée pour chaque pool de mémoire.
Maintenant cependant, le pilote kmem est activé par défaut pour cgroup v1 et v2. Et comme les systèmes modernes ont tendance à créer un grand nombre de groupes c, l'utilisation de SLAB est moins efficace.
Selon lui, en partageant les pages de dalle entre différents groupes de mémoire et en utilisant un système retravaillé où la comptabilité se fait par objet plutôt que par page, on aurait dans le noyau linux un contrôleur de mémoire optimisé qui offre un niveau d'utilisation beaucoup plus efficace.
Le correctif proposé par Gushchin contient deux éléments semi-indépendants: une API de chargement de sous-page qui peut être utilisée à l'avenir à des fins de comptabilité, et une API mem_cgroup_ptr.
Tests réalisés avec le nouveau contrôleur La mémoire de Gushchin ont montré qu'il est possible d'obtenir entre 35% et 42% de mémoire en plus sous Linux sur le Web frontal, le cache de base de données et le serveur DNS, et de nombreuses autres charges de travail.
La proposition de Gushchin est actuellement sous la bannière de «demande de commentaire». S'il est accepté, il pourrait être intégré à la version 2020 du noyau Linux.
source: https://lkml.org/