Meta Presented CRAM, Its Compressed-Memory Work for Linux

Meta engineer Gregory Price presented Meta’s tested Compressed RAM (CRAM) service for Linux at Linux Plumbers Conference on October 5, 2026. The implementation was identified as mm/cram.c; its design pairs hardware-offloaded compression with memory access intended to behave more like ordinary RAM than conventional compressed swap. The conference session describes the project and its reported test scope.

Meta presented CRAM for Linux

CRAM is an in-development compressed-memory service. In the conference presentation, Price described a tested implementation and reported near-native DRAM performance under TAOBench and FIO. The abstract also reports page-cache correctness testing under most in-tree filesystems.

Those results concern the tested CRAM service. They are not a comparison of an isolated compression algorithm against Zstd.

How CRAM is described to access compressed memory

CRAM offloads compression to hardware while retaining cacheline- and byte-level access to compressed memory. In the design Price described, that memory can remain mapped in page tables and present in the page cache without a read-access fault or software decompression on each read.

That access model is the key distinction from the ZRAM and Zswap approaches described in the session. The aim is to make compressed memory more directly usable, rather than treating it simply as data that must be decompressed when read back.

What the reported performance results cover

Price’s abstract characterizes CRAM’s performance under TAOBench and FIO as near-native to DRAM. A reported read-only comparison also placed CRAM reads at raw DRAM speed. The displayed read comparison included ZRAM, Zswap and disk swap; an annotation flagged a reclaim-stall issue affecting the Zswap result.

For writes, the presentation reported faster results than ZRAM, Zswap and plain swap. A slide headline reported a 5–37× advantage over ZRAM in the write cases shown, which included skewed workloads (Zipf 0.99) and uniform-random workloads labeled worst-case. That ratio belongs to those displayed cases, not to every workload or to the comparisons with Zswap and plain swap.

The kernel support areas behind the work

The session identified several kernel features relevant to supporting CRAM: anonymous memory, page cache, reclaim and demotion, memory ballooning, free-page reporting, memory tiering, and controlled NUMA allocation. The abstract said all but one of the required features either already existed in the kernel or had existed at one time.