SLAB ha delle pagine di memoria (ovvero delle porzioni continue) assegnate dal kernel; quando al kernel arriva una richiesta di uso della memoria stessa, a seconda della dimensione dell’oggetto da gestire SLAB sceglie quale pagina usare, in modo che oggetti di dimensione simile siano memoriazzati nella stessa pagina – magari riusando uno slot liberato da un altro oggetto. Le richieste sono messe in una queue (coda), per essere elaborate una dietro l’altra.

Nei sistemi moderni, viene creata una coda SLAB per ogni processore e per ogni cgroup. Se poi è attivo kmem, ogni SLAB memorizza anche a quale processo ogni pagina appartenga.

Tra i compiti del kernel, in qualsiasi sistema operativo, c’è la gestione delle risorse, ivi compresa l’assegnazione di memoria per degli “oggetti” – che possono essere i dati usati da un programma, o il programma stesso, o il driver di una periferica: per il kernel è solo assegnazione di memoria. Per eseguire in maniera efficiente questo compito esiste il gestore di memoria SLAB.

Roman Gushchin, ingegnere di Facebook per lo sviluppo del kernel, ha notato che l’uso dei sistemi di cache di SLAB con kmem è poco efficiente: circa il 40% delle richieste non ha risposta immediata. Cercando le cause, le ha individuate nell’alto numero di cgroup presenti normalmente nel sistema (per via dell’uso massiccio di container e systemd cough… cough…) e nella netta separazione delle pagine di memoria usate dai vari SLAB creati. Questo porta anche ad uno spreco di memoria: la memoria assegnata ma non usata da uno SLAB non può essere usata (anche) da un altro.

La soluzione proposta da Roman consiste nel condividere le pagine di memoria tra gli SLAB, assegnando alla gestione del singolo SLAB non la pagina stessa ma i singoli oggetti memorizzati. In questa maniera, una pagina di memoria assegnata ad uno SLAB potrà essere usata anche da un altro, rendendo più efficiente l’uso della memoria.
Per fare questo il meccanismo kmem deve essere portato fuori dai singoli SLAB, in modo che anche quelle informazioni siano condivise, e deve tenere traccia della proprietà dei singoli oggetti e non delle intere pagine.

I suoi primi test sono stati un miglioramento nell’uso della memoria del 40%, in varie situazioni di carico. Esistono ancora delle aree in cui la nuova implementazione potrebbe funzionare peggio, ma sembrano relegate a situazioni particolari e poco probabili. Va notato infine come i test siano generici: non hanno preso a modello situazioni interne a Facebook (cosa che poteva essere naturale) né usato OS particolari (una banale Fedora 30).

La patch è in RFC (Request For Comments – Richista di commenti), ovvero in quella fase per cui gli sviluppatori discutono della bontà della proposta: non dovessero esserci obiezioni, si passerebbe alla fase di integrazione.

Potremmo quindi trovare la nuova implementazione disponibile già l’anno prossimo: pronti a snellire Linux?

Marco Bonfiglio

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.