Il 5 ottobre 2026, a Linux Plumbers Conference, l’ingegnere di Meta Gregory Price ha presentato CRAM, un servizio di memoria compressa per Linux in sviluppo, identificato nell’implementazione testata come mm/cram.c. Il progetto affida la compressione all’hardware e punta a lasciare i dati compressi accessibili come memoria, anziché trattarli come pagine da recuperare e decomprimere a ogni lettura. La sessione ufficiale descrive il funzionamento previsto e i test presentati.
Meta presenta CRAM per Linux
Compressed RAM, abbreviato CRAM, è il servizio di memoria compressa illustrato da Price. Il codice dell’implementazione testata è indicato come mm/cram.c: si tratta di un lavoro in sviluppo, non del nome di una funzione già integrata in una versione di Linux.
La differenza centrale rispetto alla memoria compressa tradizionale sta nel modo in cui si accede ai dati. Nella descrizione del progetto, l’hardware si occupa della compressione e CRAM conserva l’accesso alla memoria compressa a livello di cacheline — il blocco di dati trasferito tra memoria e cache — e di singolo byte.
Come viene descritto l’accesso alla memoria compressa
Il modello presentato prevede che la memoria compressa possa restare mappata nelle page table, le strutture che collegano gli indirizzi usati dai programmi alle pagine di memoria, e presente nella page cache. In questo modo, una lettura non dovrebbe richiedere un page fault per avviare la decompressione né un passaggio di decompressione software.
È una differenza architetturale rispetto a ZRAM e Zswap, che compaiono come termini di confronto nella presentazione. La descrizione di CRAM riguarda un servizio con compressione affidata all’hardware e accesso diretto ai dati compressi: i risultati di prestazione, quindi, riguardano il servizio nel suo insieme, non un confronto isolato tra algoritmi di compressione.
Che cosa coprono i risultati riportati
L’abstract della sessione attribuisce a CRAM prestazioni vicine a quelle della DRAM nei test TAOBench e FIO. Riferisce inoltre prove di correttezza della page cache con la maggior parte dei filesystem inclusi nel kernel. Questi risultati descrivono test specifici del servizio.
Una slide della presentazione riportava un vantaggio in scrittura da 5 a 37 volte rispetto a ZRAM nei casi mostrati. I grafici distinguevano carichi sbilanciati, con distribuzione Zipf 0,99, e accessi casuali uniformi, indicati come caso peggiore: l’intervallo riguarda quelle prove, non tutte le operazioni o configurazioni possibili.
Il grafico sulle letture confrontava dati in sola lettura con la DRAM e altre soluzioni; una nota segnalava un problema di reclaim stall nei risultati di Zswap, che rendeva quel confronto non del tutto valido. Il dato relativo a Zswap va quindi considerato entro quella specifica prova, non come una misura lineare delle prestazioni generali.
Le aree del kernel coinvolte
L’abstract elenca varie funzioni di gestione della memoria necessarie a un servizio come CRAM: memoria anonima, page cache, reclaim e demotion, ballooning, segnalazione delle pagine libere, memory tiering e allocazione NUMA controllata. In breve, il lavoro tocca sia il recupero della memoria sia il suo spostamento tra livelli e nodi diversi.
Price indicava che tutte tranne una delle funzionalità richieste erano già presenti nel kernel o lo erano state in passato. Si tratta dei componenti di supporto: il dato non equivale all’integrazione del servizio CRAM stesso.
