Linux cambia ZRAM: più memoria disponibile e prestazioni migliori

Recuperare memoria senza installare un solo modulo RAM in più sembra quasi un controsenso, eppure è esattamente il principio su cui Linux lavora da tempo con ZRAM. Il kernel comprime alcune pagine di memoria e le conserva nella RAM stessa, evitando quando possibile il passaggio verso uno swap su SSD o hard disk tradizionale. Ora questa tecnologia sta ricevendo una revisione importante: una serie di patch pubblicate a inizio ottobre 2026 punta a ridurre la memoria consumata internamente da ZRAM e, nello stesso tempo, ad abbassare le latenze nei percorsi di compressione e decompressione.

Il lavoro arriva da Sergey Senozhatsky, sviluppatore del team Chrome/Chromium di Google e nome da tempo legato allo sviluppo di ZRAM. La modifica non riguarda quindi un nuovo algoritmo miracoloso di compressione, ma qualcosa di più profondo: il modo in cui il sottosistema organizza i dati internamente, distribuisce il lavoro tra le CPU e gestisce letture, scritture e ricompressione.

Perché Linux sta cambiando il funzionamento di ZRAM

ZRAM accompagna Linux da oltre 15 anni ed è ormai utilizzata in scenari molto diversi: notebook, desktop, dispositivi embedded, sistemi ChromeOS e macchine dove la memoria rappresenta una risorsa particolarmente preziosa.

Un processore riesce spesso a comprimere e decomprimere una pagina di memoria molto più rapidamente di quanto il sottosistema di storage impieghi a trasferirla da e verso un dispositivo di swap. Da qui nasce un risultato che a prima vista può sembrare controintuitivo: spendere risorse della CPU per comprimere la RAM può rendere il computer più reattivo.

Il cuore della revisione riguarda infatti zcomp, il livello utilizzato da ZRAM per interfacciarsi con gli algoritmi di compressione.

Uno dei problemi individuati riguarda il modo in cui ZRAM gestisce contemporaneamente le operazioni di compressione e decompressione. Finora alcune risorse interne potevano essere condivise tra i due lavori: quando il sistema era molto impegnato, un’operazione poteva quindi trovarsi ad aspettare che l’altra terminasse.

La nuova soluzione separa meglio le due attività: lettura e scrittura dei dati compressi possono procedere con minori interferenze reciproche. Linux evita alcune attese inutili proprio nei momenti in cui la memoria è sotto pressione e ZRAM lavora più intensamente.

Il vantaggio non dipende quindi da un nuovo algoritmo di compressione, ma da una gestione più efficiente delle operazioni già esistenti: meno contese interne significa che il processore può comprimere e recuperare le pagine di memoria con maggiore regolarità, soprattutto quando molte richieste arrivano nello stesso momento.

Una ZRAM più veloce, ma anche meno affamata di memoria

Un’altra ottimizzazione riguarda la ricompressione: ZRAM può infatti prendere dati già compressi e sottoporli a un secondo algoritmo, più efficace nel ridurne le dimensioni.

L’idea è semplice: usare inizialmente un compressore molto veloce e, in un secondo momento, provare a recuperare ulteriore spazio sulle pagine che restano a lungo nella memoria compressa.

Finora questa funzione poteva riservare più memoria interna del necessario, soprattutto sui sistemi dotati di molti core. Le nuove patch riducono tale overhead condividendo meglio le risorse impiegate per la ricompressione. Il risultato è particolarmente interessante con algoritmi come Zstandard, Deflate e LZ4HC, che possono richiedere strutture di lavoro più pesanti rispetto ai compressori più semplici.

In pratica ZRAM continua a offrire gli stessi meccanismi, ma con una gestione interna più parsimoniosa: meno RAM utilizzata per far funzionare il sistema di compressione significa più memoria che può restare a disposizione delle applicazioni.

ZRAM contro lo swap classico: CPU al posto dell’I/O

Con lo swap tradizionale, quando la memoria si riempie, il kernel può trasferire pagine poco utilizzate dalla RAM verso una partizione o un file presente sullo storage: lo spazio disponibile sul disco supera normalmente di molto la capacità della RAM. Il prezzo da pagare è la latenza.

Anche un buon SSD NVMe resta, tuttavia, ordini di grandezza più lento della memoria principale per molte operazioni, soprattutto quando entrano in gioco accessi casuali e code I/O. Con un hard disk la differenza cresce enormemente.

Se il sistema entra in una condizione di “pressione” intensa e passa continuamente pagine avanti e indietro, può comparire il classico fenomeno del thrashing: gran parte del tempo finisce speso nella gestione dello swap anziché nell’esecuzione del lavoro utile.

ZRAM cambia il compromesso: le pagine non lasciano la memoria; Linux le comprime, recupera parte dello spazio e, quando servono nuovamente, le decomprime. Il costo passa quindi dallo storage alla CPU.

Non significa però che ZRAM sia sempre la scelta migliore: se il workload utilizza dati scarsamente comprimibili oppure se la CPU rappresenta già il collo di bottiglia, il beneficio diminuisce. Inoltre ZRAM continua a consumare memoria fisica: se la pressione cresce oltre una certa soglia non dispone, da sola, della capacità virtualmente enorme che può offrire uno swap su SSD.

ZRAM e zswap non sono la stessa cosa

La distinzione con zswap è ancora più importante. Le due tecnologie sono spesso accomunate perché entrambe comprimono pagine destinate allo swap, ma operano in modo diverso.

ZRAM crea un vero dispositivo a blocchi compresso residente in memoria e può essere configurato direttamente come swap; zswap, invece, funziona come una cache compressa davanti a uno swap tradizionale.

Quando Linux decide di espellere una pagina dalla memoria, zswap prova prima a comprimerla e conservarla nel proprio pool RAM; se il pool raggiunge i limiti previsti, alcune pagine possono essere trasferite al dispositivo di swap sottostante.

Con ZRAM lo swap stesso risiede nella RAM compressa; con zswap resta disponibile un backing store su disco, che rappresenta una seconda linea di difesa quando la memoria compressa non basta.

Abbiamo analizzato nel dettaglio architettura, configurazione e casi d’uso nell’approfondimento zswap vs zram: quale scegliere per la memoria Linux.

Usare entrambe contemporaneamente è tecnicamente possibile, ma raramente rappresenta una configurazione sensata: si rischia di sovrapporre più livelli di compressione e rendere meno prevedibile il comportamento del sistema sotto pressione. In genere conviene capire prima quale problema si vuole risolvere e scegliere di conseguenza.

Più RAM senza aggiungere RAM? Sì, ma con una precisazione

Dire che ZRAM “aumenta la RAM” è una semplificazione che non è fuori luogo. Tuttavia, la capacità fisica ovviamente non cambia e la compressione non può aggirare indefinitamente i limiti dell’hardware. Quello che cambia è l’efficienza con cui Linux sfrutta la memoria disponibile.

Se un insieme di pagine occupa 1 GB non compresso ma può essere conservato in 400 o 500 MB, il sistema recupera centinaia di megabyte da destinare ad applicazioni, cache del file system o altre attività. Se per ottenere il risultato bastano brevi operazioni di compressione su CPU, il compromesso può risultare enormemente più conveniente di una serie di letture e scritture sullo storage.

La revisione proposta non cambia l’idea di fondo: la rende più efficiente intervenendo in contemporanea sui due costi storici di ZRAM ovvero RAM occupata dall’infrastruttura e tempo CPU necessario per gestire le pagine compresse.