Il tuo sistema Linux stava andando bene, poi hai aperto troppi tab, lanciato una VM e compilato qualcosa in background. Il kernel ha iniziato a swappare. La domanda non è se hai dello swap attivo — la domanda è quanto hai capito di cosa sta succedendo dentro il memory subsystem prima di scegliere tra zswap e zram.
Entrambe le tecnologie esistono nel kernel Linux da anni. Entrambe comprimono le pagine di memoria prima che finiscano su disco. Eppure si comportano in modo fondamentalmente diverso, fanno scommesse opposte su come gestire la memory pressure, e scegliere quella sbagliata per il tuo workload può peggiorare le prestazioni rispetto a non avere nessuna delle due.
La confusione nasce dal fatto che la maggior parte delle persone pensa a zswap e zram semplicemente come a due varianti della stessa cosa: compressed swap. A livello superficiale è corretto — entrambe comprimono pagine che altrimenti finirebbero su disco — ma fanno scommesse fondamentalmente diverse su come il kernel dovrebbe gestire la memory pressure. Vediamo cosa nasconde davvero questo confronto.
- 👉 zram crea un block device compresso interamente in RAM; non richiede swap su disco, ma ha un limite di capacità fisso e non fa eviction automatica
- 👉 zswap è una cache compressa che si interpone tra la RAM e lo swap su disco; fa eviction LRU e degrada in modo controllato sotto pressione
- 👉 I due non vanno usati insieme: si sovrappongono e si ostacolano a vicenda
- 👉 Per desktop/server moderni con SSD NVMe: zswap è generalmente la scelta migliore
- 👉 Per sistemi embedded, diskless o con requisiti di sicurezza sulla persistenza: zram può avere senso
Come funziona davvero zram (non la versione semplificata)
Quando il sistema identifica una pagina di memoria come candidata allo swap, zram la comprime prima di scriverla su un block device dedicato che risiede interamente in RAM. Niente disco, niente I/O tradizionale. Le latenze di accesso sono nell’ordine dei microsecondi, non dei millisecondi.
Caricando il modulo e inizializzando un block device con zramctl, viene creato un compressed block device in RAM che si può formattare come un disco ordinario. Quando lo si usa come swap, le pagine vengono compresse al 50–30% della dimensione originale prima di essere memorizzate in RAM invece di essere scritte su disco.
Il problema è architetturale: zram fornisce un limite di capacità fisso, e quando il device si riempie il kernel ha pochissima leva. Il sistema va in OOM oppure ricade su swap a priorità inferiore, causando LRU inversion. Se hai configurato zram a 8 GB su un sistema con 16 GB di RAM e il workload cresce oltre quella soglia, quando zram si riempie le prestazioni crollano: circa 8 GB di RAM fisica vengono occupati dal compressed swap, lasciando solo 8 GB per il working set e le cache.
Un altro problema riguarda gli ambienti containerizzati: su server, zram ha il problema aggiuntivo che il suo utilizzo di memoria è completamente segregato dal resto del sistema, e quindi non viene imputato a nessun cgroup, rompendo la semantica di isolamento.
Come funziona davvero zswap
zswap è una feature del kernel Linux che fornisce una compressed write-back cache per le pagine di swap. Invece di spostare le pagine di memoria su un device di swap quando devono essere swappate, zswap le comprime e le memorizza in un memory pool allocato dinamicamente nella RAM di sistema. Il writeback effettivo sul device di swap viene differito o addirittura evitato, con una significativa riduzione dell’I/O.
La differenza chiave rispetto a zram è il meccanismo di eviction: zswap espelle le pagine dalla cache compressa su base LRU verso il backing swap device quando il pool compresso raggiunge il suo limite di dimensione. Quando il pool è pieno, le pagine meno recentemente usate vengono scritte su disco — non si arriva a un blocco catastrofico del sistema.
Per dirla in altro modo: zram fornisce un limite di capacità fisso, mentre zswap fornisce un tiering automatico tra storage più veloce (RAM compressa) e swap più lento (disco) e degrada in modo controllato all’aumentare della memory pressure. Per la maggior parte degli utenti, il graceful degradation è ciò che si vuole.
zswap richiede uno swap device (partizione o file) come backing storage. Non è un’alternativa allo swap tradizionale: è un acceleratore che si mette davanti.
Algoritmi di compressione e allocatori
Nei kernel ufficiali, l’algoritmo di compressione predefinito è zstd, ma può essere cambiato con zswap.compressor= al boot. Le altre opzioni includono deflate, lzo, 842, lz4 e lz4hc. zsmalloc ha sostituito zbud come allocatore di memoria a partire dalla versione 6.18 del kernel Linux, rilasciata il 1° dicembre 2025, garantendo una densità di storage compresso superiore.
Il confronto pratico: scenari reali
Desktop con workload pesante (VM, browser con molti tab, container): su una workstation con soli 16 GB di RAM e workload che superano routinariamente i 20 GB, zswap è spesso la scelta migliore rispetto a zram su storage NVMe moderno.
Server e ambienti VPS: zswap riduce le operazioni di swap su disco del 60–80% tramite caching intelligente. Per workload misti che richiedono sia i benefici della compressione sia una grande capacità di swap, zswap è la scelta preferibile.
Sistemi embedded o diskless: zram è l’opzione corretta quando non c’è affatto un backing swap device, oppure quando si vuole garantire che dati sensibili non tocchino mai lo storage persistente.
Sistemi con CPU molto lente (sotto 1 GHz): con velocità CPU inferiori a 1 GHz ci sarà un impatto sulle prestazioni. In questo caso, né zram né zswap sono necessariamente vantaggiosi.
Non usarli insieme
zswap non deve essere usato insieme a zram. Entrambi forniscono una cache compressa e finirebbero per usare più memoria di sistema rispetto a ognuno individualmente. zram può funzionare insieme a un normale swap file, ma non insieme a zswap: duplicano il lavoro dell’altro sprecando la risorsa stessa che vogliono conservare.
Configurazione: parametri essenziali
Per zswap
zswap può essere attivato e disattivato a runtime scrivendo 1 o 0 in /sys/module/zswap/parameters/enabled.
Per abilitarlo in modo permanente tramite parametri kernel (GRUB):
zswap.enabled=1 zswap.max_pool_percent=20 zswap.compressor=zstdIl parametro max_pool_percent specifica la percentuale massima della RAM totale occupabile dal pool. Il pool non è preallocato: cresce e si riduce secondo necessità.
Per zram
- Caricare il modulo:
modprobe zram - Impostare la dimensione:
echo 4G > /sys/block/zram0/disksize - Impostare l’algoritmo:
echo zstd > /sys/block/zram0/comp_algorithm - Formattare e attivare:
mkswap /dev/zram0 && swapon /dev/zram0 -p 100
zram tipicamente performa bene quando configurato al 25–50% della RAM disponibile. Il vm.swappiness dovrebbe essere aumentato verso 180 quando si usa zram, poiché i costi di swap sono molto inferiori rispetto al disco.
Tuning di vm.swappiness
Con zswap, un valore di vm.swappiness tra 60 e 100 è ragionevole; con zram su desktop, un valore di 50 bilancia bene swapping e caching. Nei server, valori tra 10 e 30 sono comunemente consigliati indipendentemente dalla tecnologia.
Quale scegliere: tabella decisionale
| Scenario | Tecnologia consigliata |
|---|---|
| Desktop moderno, SSD/NVMe, RAM ≥ 8 GB | zswap |
| Server, VPS, carichi misti | zswap |
| Sistema embedded, diskless | zram |
| Dati sensibili che non devono toccare disco | zram |
| CPU molto lenta (< 1 GHz) | Swap tradizionale |
| Ibernazione (hibernation) | zswap |
💡 Regola pratica: in caso di dubbio, preferire zswap. Usare zram solo se c’è una ragione altamente specifica per farlo.
Vuoi approfondire questo argomento?
Ho realizzato un video dedicato su YouTube @tuttelevitediunmaker dove confronto zswap e zram su un desktop Linux con 16 GB di RAM sotto carico reale: VM attive, browser pesante e compilazione in background — esattamente il tipo di scenario in cui la scelta sbagliata può costare caro. Se vuoi supportare questo progetto e accedere a contenuti esclusivi sull’ottimizzazione dei sistemi Linux e sulla sicurezza, trovi tutto su Patreon.
👉 YouTube @tuttelevitediunmaker | Patreon
#tuttelevitediunmaker
FAQ — Domande Frequenti
Posso usare zswap e zram contemporaneamente?
No. Entrambi operano come cache compresse per le pagine di swap e, se usati in parallelo, si sovrappongono nel consumo di RAM senza offrire vantaggi aggiuntivi. Il risultato è un uso di memoria superiore rispetto a ciascuno dei due separatamente.
zswap funziona senza uno swap file o una partizione di swap?
No. zswap è una cache che si interpone tra la RAM e un backing swap device. Senza uno swap file o una partizione di swap attiva, zswap non può operare: richiede quel device come destinazione finale per le pagine evase dal pool compresso.
Qual è l’algoritmo di compressione migliore per zswap?
Nei kernel ufficiali moderni il default è zstd, che offre un ottimo equilibrio tra rapporto di compressione e velocità. lz4 è un’alternativa più rapida ma con compressione leggermente inferiore. lz4hc bilancia entrambi i parametri ed è spesso consigliato per workload interattivi dove la latenza conta.
zswap è abilitato di default su Ubuntu e Arch Linux?
Il modulo è presente nei kernel ufficiali. Su Ubuntu 24.04 il modulo è caricato di default, ma occorre abilitarlo esplicitamente via sysfs o parametro kernel. Su Arch Linux con kernel ufficiale, zswap è abilitato di default e verificabile con zgrep CONFIG_ZSWAP_DEFAULT_ON /proc/config.gz.
zram è ancora una buona scelta nel 2025–2026?
Per desktop generici con NVMe moderni, zswap tende a performare meglio sotto carichi elevati grazie all’eviction LRU. zram rimane valido per sistemi embedded, dispositivi diskless, Raspberry Pi, e casi dove non si vuole che dati sensibili tocchino lo storage persistente. Fedora Asahi Remix ha recentemente abbandonato la configurazione zram+swap in favore di zswap dopo aver riscontrato problemi di OOM prematuri.
Come verifico se zswap sta effettivamente comprimendo le mie pagine?
Esegui: grep -r . /sys/kernel/debug/zswap/. I campi chiave sono stored_pages (pagine attualmente nel pool compresso), written_back_pages (pagine evase su disco) e pool_total_size (dimensione totale del pool in byte). Se stored_pages cresce durante la memory pressure, zswap sta lavorando.
Conclusione
zswap e zram non sono intercambiabili: rispondono a filosofie diverse di gestione della memoria sotto pressione. zswap offre un tiering automatico e un degrado controllato che lo rende più robusto su desktop e server moderni; zram è uno strumento chirurgico per scenari specifici dove il disco non c’è o non deve essere coinvolto. Il kernel ha fatto la sua scelta — nei kernel ufficiali recenti, zswap è abilitato di default con zstd. Il fatto che molti utenti ancora non lo sappiano è esattamente il tipo di dettaglio che fa la differenza tra un sistema che regge e uno che va in OOM al momento sbagliato.
Approfondisci il tema sul canale YouTube @tuttelevitediunmaker, dove il memory management Linux è solo uno degli argomenti trattati senza semplificazioni.
#tuttelevitediunmaker
