Proposto un nuovo gestore di memoria per Linux che la riduce
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?
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
