Meta’s CRAM Proposal Lets Linux Read Compressed Memory Without Swapping It Back

That is an interesting change for machines whose working sets no longer fit comfortably in conventional RAM. It also introduces a capacity-planning problem: how much memory does the machine have when the answer depends on the data stored in it?

Gregory Price presented A Compressed RAM Service at Linux Plumbers Conference on October 5. The proposed service lets compressed memory remain mapped into an application’s address space. Reads do not need the software decompression and fault handling associated with bringing a page back from compressed swap. Hardware still has work to do; this does not make decompression free.

Why this differs from zram and zswap

Zram provides a compressed, RAM-backed block device. When used as swap, it keeps swapped-out data in memory instead of requiring a disk read. The application still accesses that data through the swap-in path, rather than reading the compressed representation directly.

Zswap is a compressed cache in front of a backing swap device. Its documentation describes the load path explicitly: a page fault causes the cached data to be decompressed into a page allocated by the fault handler. It can reduce storage traffic considerably, but a cache hit does not remove the fault.

CRAM targets that remaining overhead. The compression hardware provides cacheline or byte access, so Linux can leave the memory mapped and service reads without first restoring an entire page through software. This is hardware-backed memory-management work, not a different compression algorithm to select in zramctl.

Writes are where the design gets complicated

Reading compressed data does not change how well it compresses. Overwriting it can.

Consider a hypothetical device with 64 GiB of physical capacity. Ignoring metadata and other overhead, data compressing at 2:1 would let it hold 128 GiB. At 1.25:1, that falls to 80 GiB. Nothing has failed electrically, but 48 GiB of effective capacity has disappeared. Those are illustrative numbers, not CRAM measurements.

I would not want a capacity alert based only on the larger number. A workload could change its data without increasing its logical allocation, and the physical space needed to hold that allocation could grow.

Price’s February RFC implementation addresses this with write protection: reads can stay in the compressed tier, while a write fault promotes the affected folio back to regular DRAM. New entries arrive through demotion, giving the device driver a way to stop accepting more when physical capacity is under pressure. The RFC also describes reclaim to swap when the device signals pressure.

That is an earlier implementation, not a guarantee of the eventual interface. The October presentation retains the direct-read, promote-on-write approach. It also identifies allocation control, dynamic sizing and accounting as requirements.

The benchmark caveat deserves space

The presentation slides state that the comparison used DRAM-backed configurations to isolate fault cost. They also warn that an unrelated reclaim stall makes the zswap results not entirely valid.

That experiment can help establish the cost of the software path CRAM avoids. It does not establish the latency of a particular compression device, or how much faster a production database would run on one. I would not use it to justify a hardware purchase or promise an application-level speedup.

The distinction matters because the proposed mechanism is worthwhile even without an enormous multiplier. Keeping frequently read data accessible without repeated swap faults could be valuable on its own. How valuable depends on where the application spends its time.

What I would test before putting a workload on it

I would start with the read/write mix, then change it during the test. A steady read-heavy benchmark could look excellent while concealing the cost of promoting pages when an application starts updating them.

For a database or cache evaluation, I would want request latency alongside promotion activity, reclaim activity and ordinary DRAM headroom. Average throughput would not tell me whether a burst of writes makes the slowest requests unacceptable. These are evaluation criteria, not results from a CRAM deployment I have run.

I would also test a less-compressible dataset at the same logical size. That separates growth in the application’s allocation from growth in the physical space needed to back it. Both need to be visible before an operator can make sensible placement decisions.

On a shared host, I would want to establish who pays when that happens. If one tenant’s data becomes harder to compress, can reclaim or promotion hurt another tenant? How do the memory limits and monitoring expose that pressure? The answers belong in an acceptance test, alongside the favorable benchmark.

CRAM is worth following because it could make compressed memory useful for more than parking pages until they are needed again. I would keep an existing zram or zswap setup while evaluating this work. Before changing it, I would need a supported hardware-and-kernel combination and measurements showing that the workload benefits under memory pressure—not just while everything fits.