Build2 publishersIndependently confirmed2 min readPublished
Meta's CRAM reads compressed Linux memory up to 452x faster than ZRAM by keeping it out of swap
Meta's Gregory Price showed Linux Plumbers a compressed-memory design, CRAM, that reads up to 452x faster than ZRAM by keeping pages out of swap. His slides still list a compressed host's usable capacity as an open problem for anyone sizing servers around it.
The Engineer · Build desk
What happened
- CRAM presents compressed memory to the kernel as a private NUMA node instead of a block device, so Linux can still migrate and balloon it like ordinary RAM.
- With writes making up 20% of operations, the worst case tested, CRAM's advantage over ZRAM fell to 5.4x.
- A "Chicken Bit" makes Linux stop using CRAM while it is busy managing allocations, so writes that outpace allocation do not set off cascading failures.
- Phoronix reports that most of the individual kernel pieces CRAM depends on are already in mainline.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Until the kernel can count logical memory on a compressed node, operators sizing memory-tight hosts have to plan as if CRAM adds no guaranteed capacity.
- decision Whether CRAM pays off on a given host depends on how often its compressed pages get written, so write share has to be profiled before choosing it over ZRAM.
- decision If CRAM is merged, distributions that ship ZRAM or zswap on by default, down to machines like the Steam Deck, would have a non-swap option to weigh for that default.
Price's premise can be checked against his own numbers. As Tom's Hardware reads the slides, compression is a small part of the cost. Most of the penalty is the fault and the swap handling around it [10]. zswap and ZRAM are both swap-layer features [11]. Reaching a compressed page in either one goes through the path Price's team found expensive [10][11].
CRAM's read path avoids that path. The compressed data sits in RAM and is treated as RAM, with full cacheline and byte access, so a read costs little beyond hardware-offloaded compression [4]. Price's slide said CRAM "runs at DRAM speed" [5]. Phoronix reports read-only data matching raw DRAM performance [6].
Writes give the premise its best evidence. Compressed data cannot be written in place. A write has to page fault and migrate the folio back to its original NUMA node [3]. If compression were the main cost, the read-only and write-mixed results would sit close together. From the read-only peak to the worst write mix tested, CRAM's lead shrinks by a factor of about 84 [19].
For the headline figure to carry over to another host, the workload has to resemble the test. The 452x number comes from a read-only case [13]. The read path also depends on hardware-offloaded compression [4], and neither report says which hardware the tests ran on. Even the worst read case reported, 489 million operations per second against ZRAM's 1.1 million, works out to about 445x [14][20].
Sizing is the harder question. Compressibility ranges from piles of zeros, which compress perfectly, to data that is already compressed. That leaves no settled way to know how much logical memory a host holds or when it will run out, and the slides list the problem as unsolved and under research [7]. The Chicken Bit acts at the moment writes outrun allocation, a cascade the presentation calls a "poison storm" [15][18]. It is a fair name. Capacity planning needs a number before that moment arrives. I would not count CRAM's compression ratio as headroom on a memory-tight host until the kernel can report what a compressed node actually holds.
Tom's Hardware's account comes secondhand from the slides. "My explanation of CRAM might not be completely correct," Tom's Hardware contributor Zak wrote, adding that he "wasn't at the Linux Plumbers' Conference in Prague to hear the presentation directly" [17]. ZRAM and zswap run across the Linux ecosystem, down to the Steam Deck, and many distributions enable one of them by default [16]. CRAM is not in the kernel yet, and Tom's Hardware expects it to land only once the remaining implementation questions are answered [9].
What to watch
- Whether Price's team proposes a way for the kernel to report usable capacity on a compressed node, the problem the slides list as open.
- CRAM patch postings for the kernel, and which of the pieces they need are still outside mainline.
- Independent benchmarks with write shares above 20%, or on hardware without compression offload.