Adding DRAM to a memory-constrained server is expensive; Meta engineer Gregory Price is proposing a faster alternative. His Compressed RAM Service proposal, presented at the Linux Plumbers Conference in Prague in October 2026, reached approximately 489 million operations per second in read-only benchmarks against roughly 1.1 million for ZRAM, a reported difference of about 452x under that specific workload. CRAM is not a shipping feature; it is a tested implementation seeking upstream Linux kernel review.
Compressed Memory as a Memory Tier, Not a Swap Layer
CRAM treats compressed storage as a directly addressable memory tier, avoiding the page-fault and decompression overhead that conventional compressed-memory systems impose on reads.
ZRAM and zswap both operate around the swap layer. Accessing that compressed data typically requires page-fault handling and software decompression before a program can read it, though the exact sequence depends on the implementation path.
CRAM assumes hardware that compresses data while preserving cache-line or byte-level access, so compressed pages stay mapped in the page table. The hardware decompresses on read, without the kernel needing to fault the page back into regular DRAM first.
Price’s design treats compressed memory more like a slower NUMA memory tier than a block device. It uses existing Linux memory-management facilities: tiering, reclaim, demotion, and NUMA allocation.
Writes are the catch. Pages placed in CRAM are treated as read-only; a write triggers a fault that migrates the page back to regular DRAM before the operation proceeds.
“Near-native performance to DRAM,” per the Linux Plumbers Conference abstract, describing CRAM’s results in TAOBench and FIO testing.
Read Performance Is Strong; Writes Tell a Different Story
The reported 452x speedup is a read-only benchmark result, and the advantage contracts sharply once writes enter the equation.
The reported 452x figure comes from a read-only benchmark comparison, not a universal application speedup. Reports based on the presentation put read-only CRAM performance at roughly 98 to 99 percent of ordinary DRAM in some tests, according to xenospectrum.com. Those comparisons used DRAM to isolate software and page-fault overhead, so they should not be read as definitive product benchmarks for real compressed-memory hardware.
Introduce writes, and the picture changes. At low write rates, CRAM runs roughly 37x faster than ZRAM; at 20 percent writes, that drops to approximately 5.4x, according to xenospectrum.com.
Workloads that modify memory frequently will see considerably less benefit than read-heavy ones. It is worth noting that the 20 percent write test included periods of substantial memory-full stalls, a reminder that even CRAM does not eliminate computer problems like memory pressure.
A deeper engineering problem remains unsolved: compression ratios vary by workload, so the kernel cannot assume a fixed amount of physical storage corresponds to a given logical allocation. Price’s proposal includes a “Chicken Bit” mechanism, per Tom’s Hardware, that stops Linux from allocating additional compressed capacity when the CRAM device is already struggling to service writes. The broader capacity-management challenge, however, remains open work.
Full upstream integration has not happened yet. The kernel mechanisms CRAM relies on already exist, but compatible hardware availability is also unresolved. CXL memory expanders with inline compression are the most plausible near-term platform, based on reporting from Hardware Busters. CRAM depends on specialized hardware that is not currently found in consumer laptops or desktop systems.
What Comes Next
The path forward depends on solving dynamic capacity accounting, refining write-fault handling, and clearing upstream kernel review.
If you run memory-intensive Linux servers or manage cloud infrastructure where adding physical DRAM is expensive, CRAM is worth tracking. No integration timeline has been confirmed.
