Meta's CRAM reads compressed Linux memory up to 452x faster than ZRAM by keeping it out of swap

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].