L'administrador de memòria és un subconjunt de sistema operatiu que comparteix la memòria entre el sistema operatiu i les diverses aplicacions. El terme memòria es refereix principalment a la memòria principal (RAM), però la seva gestió requereix la contribució de la memòria auxiliar i la memòria cau.
L'administrador de memòria és especialment responsable d'assignar eficientment la memòria als processos, El que implica que ha de ser capaç d'enumerar les ubicacions lliures de la memòria disponible, assignar la memòria necessària per als nous processos i recuperar la memòria dels processos que acaben. El assignador de processos dins de el nucli de Linux és el assignador SLAB.
SLAB es basa en un sistema de bloc i cau que optimitza les sol·licituds de memòria. Aquest tipus de gestió de memòria redueix la fragmentació causada per les operacions d'assignació i reubicació.
L'assignació de blocs implica la implementació d'un cau per a un determinat tipus / mida d'objecte que té diversos blocs de memòria preassignats tallats en peces de mida fixa que són adequades per a objectes específics.
SLAB gestiona les peces perquè quan se sol·liciti a l'nucli l'assignació de memòria a un objecte, pugui satisfer aquesta sol·licitud amb una peça lliure d'un bloc existent. SLAB reté la memòria assignada per a la seva reutilització, quan les assignacions posteriors d'objectes similars, i per tant redueix els costos generals relacionats amb la inicialització de l'objecte.
Pretenen substituir SLAB
Novel·la Gushchin, membre de l'equip d'enginyeria de nucli de Linux al Facebook, va descobrir el que ell veu com un «defecte greu» al controlador / administrador de memòria actual. I recientemente va proposar un nou controlador de memòria de bloc que promet millorar dràsticament la utilització de la memòria entre múltiples «cgroups» (O grups de control) de memòria.
Davant d'això és important tenir en compte que cgroups es refereix a una característica el nucli de Linux que permet limitar, comptar i aïllar l'ús dels recursos d'un sistema (processador, memòria, ús de disc, etc.) i el terme «pàgina de llosa »podria assimilar-se a procés d'assignació de memòria per SLAB.
Segons Gushchin:
«La veritable raó per la qual el disseny existent condueix a un baix ús de SLAB és simple: les pàgines de llosa s'usen exclusivament per un sol grup de memòria.
Si només hi ha unes poques assignacions de certa grandària fetes per un cgroup o si queden alguns objectes actius després que el cgroup ha estat eliminat o si l'cgroup conté una aplicació de subprocés únic que no assigna pràcticament cap nucli, però ho fa cada vegada en una nova CPU: en tots aquests casos, l'ús resultant de SLAB és molt baix.
Si el càlcul de kmem està deshabilitat, el nucli pot usar l'espai lliure a les pàgines de lloses per a altres assignacions «.
Gushchin argumenta que això no va ser un problema quan es va introduir el controlador kmem com una funció opcional que havia de habilitar per a cada grup de memòria.
Ara, però, El controlador kmem està habilitat per defecte per cgroup v1 i v2. I com els sistemes moderns tendeixen a crear una gran quantitat de grups c, l'ús de SLAB és menys efectiu.
Segons ell, a l'compartir les pàgines de slab entre diversos grups de memòria i a l'usar un sistema reelaborat on la comptabilitat es realitza per objecte en lloc de per pàgina, un tindria en el nucli de Linux un controlador de memòria optimitzat que ofereix un nivell d'ús Molt més eficient.
El pegat proposat per Gushchin conté dos elements semi-independents: una API de càrrega de subpàgina que es pot utilitzar en el futur amb fins comptables i una API mem_cgroup_ptr.
Les proves realitzades amb el nou controlador de memòria de Gushchin han demostrat que és possible obtenir entre un 35% i un 42% més de memòria a Linux a la web front-end, la memòria cau de la base de dades i el servidor DNS i en moltes altres càrregues de treball.
La proposta de Gushchin es troba actualment sota la bandera de «sol·licitud de comentaris». Si s'accepta, podria integrar-se en la versió de el nucli de Linux per a 2020.
font: https://lkml.org/