CRAM sfida ZRAM su Linux: fino a 452x, ma solo nei test di lettura

🐧 Novità principali

• CRAM tratta la memoria compressa come un livello di memoria indirizzabile invece di trasformarla in swap.
• Il picco fino a 452x rispetto a ZRAM riguarda un benchmark di sola lettura e non rappresenta un incremento generale delle prestazioni Linux.
• Con il 20% di scritture il vantaggio scende a circa 5,4x e rimangono aperti problemi di capacità, hardware e integrazione upstream.

Meta prova a eliminare uno dei costi nascosti della memoria compressa su Linux: non la compressione in sé, ma il percorso attraverso fault, swap e ricostruzione delle pagine prima che possano essere utilizzate. CRAM, Compressed RAM Service, propone di trattare la memoria compressa come un vero livello della gerarchia NUMA, mantenendo le pagine mappabili e leggibili direttamente attraverso hardware capace di decomprimerle. I benchmark presentati alla Linux Plumbers Conference mostrano risultati impressionanti, ma il numero 452x rispetto a ZRAM vale in condizioni specifiche di sola lettura. Con le scritture, il vantaggio si riduce drasticamente.

CRAM vuole eliminare lo swap dal percorso della memoria compressa

Nella sessione ufficiale della Linux Plumbers Conference 2026 Gregory Price di Meta descrive CRAM come un servizio nel quale la memoria compressa continua a comportarsi, per quanto possibile, come memoria normale: può rimanere mappata nelle page table e presente nella page cache, senza richiedere un fault e una decompressione software per ogni lettura. ZRAM e zswap lavorano invece intorno al sottosistema di swap; CRAM prova a spostare la compressione dentro la gerarchia della memoria utilizzando nodi NUMA privati, demotion, reclaim, ballooning e memory tiering già presenti o già sperimentati nel kernel. L’approccio arriva mentre Linux kernel 6.19 continua a espandere la gestione di memoria, filesystem e virtualizzazione, segnalando quanto il memory management stia diventando centrale anche per server e workload AI.

Leggi anche: AMD e Meta insieme per il riciclo di RAM con CXL

Il 452x esiste ma non significa Linux 452 volte più veloce

Il dato più spettacolare necessita quindi di contesto. La ripresa tecnica delle slide di Price riporta nel caso read-only circa 489 milioni di operazioni al secondo per CRAM contro circa 1,1 milioni per ZRAM, da cui deriva il picco vicino a 452x. Non è un benchmark dell’intero sistema operativo, né dimostra che applicazioni e server diventino centinaia di volte più veloci: misura il costo di accesso a una particolare forma di memoria compressa quando non è necessario gestire scritture. Il risultato è comunque importante perché mostra che la penalità principale di ZRAM può risiedere nel percorso software e nei page fault più che nella decompressione stessa, un tema già emerso con Linux 6.8 e l’evoluzione di zswap e del memory management.

Le scritture riportano CRAM sulla terra

Il vantaggio cambia appena il workload smette di essere prevalentemente read-only. I dati mostrati nella presentazione indicano che con una quota di scritture del 20% CRAM mantiene un vantaggio nell’ordine di 5,4x rispetto a ZRAM, ma perde quasi completamente l’effetto spettacolare del benchmark di lettura. Il motivo è architetturale: i dati compressi non possono essere modificati liberamente in place senza compromettere la rappresentazione compressa, quindi un write fault richiede di promuovere nuovamente la pagina verso memoria ordinaria. Il progetto utilizza write protection e meccanismi di controllo per impedire che una perdita improvvisa del rapporto di compressione provochi una cascata di allocazioni impossibili da soddisfare. È proprio questa gestione dinamica della capacità a distinguere un prototipo veloce da un sottosistema pronto per produzione, soprattutto su architetture CXL già validate con Linux enterprise da Samsung e Red Hat.

CRAM dipende dall’hardware e non è ancora una funzione pronta per desktop

Un altro limite riguarda l’hardware. CRAM nasce pensando a dispositivi capaci di offrire accesso byte o cacheline alla memoria compressa e decompressione assistita, non alla normale RAM installata oggi in un notebook. Il bersaglio naturale sono server, espansori di memoria e architetture CXL dove il costo della capacità fisica diventa abbastanza elevato da giustificare un livello compresso più lento della DRAM ma molto più rapido dello swap tradizionale. Questo rende prematuro presentare CRAM come sostituto immediato di ZRAM su desktop, Steam Deck o distribuzioni Linux comuni. Il vero interesse è nei sistemi nei quali ogni gigabyte fisico ha un costo industriale elevato: i data center AI stanno già ridisegnando CPU, memoria e interconnessioni per aumentare la densità di compute, e una memoria compressa quasi trasparente al kernel potrebbe diventare un nuovo livello della stessa architettura.

Continua con:

NVIDIA ridimensiona Rubin Ultra, Meta riutilizza la DDR4 per contenere i costi dell’AI

CRAM è interessante proprio perché il benchmark da 452x non basta

Il progetto di Meta va quindi letto al contrario rispetto al titolo facile del “Linux 452 volte più veloce”. Il risultato realmente interessante è che spostando la memoria compressa fuori dalla semantica dello swap è possibile avvicinare alcune letture alle latenze della DRAM, riutilizzando gran parte dei meccanismi già presenti nel kernel. Restano però da risolvere problemi decisivi: stimare quanta capacità logica sia realmente disponibile quando il rapporto di compressione cambia, controllare le scritture, gestire la pressione di memoria, definire l’hardware compatibile e completare il percorso upstream. CRAM non è ancora una funzione Linux pronta per gli utenti e il 452x non è un moltiplicatore universale. È però un segnale molto più importante per server e infrastrutture: la prossima espansione della memoria potrebbe arrivare non aggiungendo soltanto DRAM, ma rendendo la capacità compressa abbastanza veloce da sembrare quasi memoria normale.