Meta's CRAM proposal treats compressed RAM as normal memory, not swap. How it works, what the 452x claim measured, and what is still missing.
Compressed RAM is an old idea with a new twist in a design Meta engineer Gregory Price presented at the Linux Plumbers Conference in Prague on October 5, 2026. Instead of treating compressed memory as a swap device that the kernel must fault pages back from, the proposal treats it as ordinary memory that happens to be backed by hardware compression, readable at cache-line granularity with no page fault and no software decompression step.
The headline figure, up to 452 times the performance of ZRAM, has been repeated widely. It does appear in the slides. It is also a best-case read-only number from tests that ran on plain DRAM, not on real compression hardware. This post explains how ZRAM and Zswap work, what CRAM changes, what the benchmark setup was, and what is still missing before anyone could run it in production.
How ZRAM and Zswap compress memory today
Linux already has two mainstream ways to squeeze more data into a fixed amount of RAM. ZRAM creates a compressed block device that lives in memory and is used as swap space. Zswap sits in front of a real swap device and keeps a compressed cache of pages on their way out. Both operate at the swap layer, which means the kernel sees a compressed page as one that has been evicted.
That has a price. When a program touches a page that was swapped out, the CPU takes a page fault, the kernel looks up the swap entry, allocates a fresh page, decompresses the stored data into it and maps it back. Kairui Song’s per-page breakdown, cited in a XenoSpectrum write-up of the talk, gives about 1.92 microseconds for page-fault handling, 1.04 microseconds for swap management and 0.32 microseconds for LZO decompression. Those add up to 3.28 microseconds, and the actual decompression is under 10 percent of it. The article describes the decompression figure as a separate measurement, so treat the sum as indicative.
The point of that arithmetic is that the codec is not the bottleneck. The software path around it is. A faster compression algorithm would barely move the total.
What CRAM changes
The abstract on the Linux Plumbers Conference session page describes devices that offload compression to hardware and still give byte- or cache-line-granular access to the compressed data. A page can stay mapped in the page tables and present in the page cache, and a read needs no fault, no copy-on-write and no software decompression. The abstract is frank about the catch: the device “fundamentally lies about its true capacity,” so the kernel’s assumption that every struct page is backed by real storage no longer holds.
CRAM, short for compressed RAM, is the service Price proposes to manage that. According to XenoSpectrum it works like this:
Pages enter CRAM during memory reclaim, not on every allocation. They live on a private NUMA node that normal allocation ignores. They are mapped read-only, so a write triggers a fault and the page moves back to regular DRAM. The device driver reports the compression ratio it actually achieved, CRAM reserves memory to match, and the driver can refuse new pages when it runs short. For file-backed memory, only unmodified pages qualify: they can be dropped and re-read, but a modified page has to return to DRAM first.
The seven kernel features it leans on
Price’s abstract says all but one of the required kernel features already exist or have existed before. It does not say which one is missing. The listed ingredients show how much of the design is assembly of existing parts:
- Anonymous memory support through page-table write protection (copy-on-write, KSM).
- Page cache support through clean cache, meaning clean pages only.
- Reclaim and demotion.
- Memory ballooning for dynamic sizing.
- Free page reporting, which trims stale data.
- Memory tiering, driven by access hotness and NUMA balancing.
- Strictly controlled NUMA allocation through private nodes.
Working through the benchmark
The numbers reported by XenoSpectrum come from a deliberately artificial setup. The test used 46 GB of anonymous memory. CRAM and the other methods were given 36 GB of physical memory, and a DRAM-only ceiling case got 54 GB.
With read-only access following a Zipf 0.99 distribution, CRAM delivered 321 million operations per second against 325 million for DRAM, about 98.8 percent. With uniformly random reads it was 489 million against 498 million, about 98.2 percent. I checked both ratios and they hold.
Then the write cases. With 2 to 20 percent writes on uniformly random access, CRAM’s throughput relative to ZRAM ranged from 37 times down to 5.4 times. In skewed access patterns, ZRAM ran out of memory at 10 and 20 percent write rates, so no like-for-like number exists there.
- Read-only, skewed: 321M vs 325M ops/s (98.8 percent of the DRAM ceiling).
- Read-only, uniform random: 489M vs 498M ops/s (98.2 percent).
- Writes of 2 to 20 percent: 37x down to 5.4x versus ZRAM.
- Skewed with 10 to 20 percent writes: ZRAM hit out-of-memory.
Where 452x comes from, and why it is not 445x
Tom’s Hardware reports the 452x figure as a ceiling for the read-only case and also quotes worst-case read throughput of 489 million operations per second for CRAM against 1.1 million for ZRAM. Divide those and you get about 445, not 452. The two numbers are probably different data points from the same chart, and the article itself notes that they are not identical measurements.
The comparison is lopsided by construction. ZRAM is being asked to fault and decompress on nearly every read of a swapped-out page, while CRAM is serving reads straight from mapped memory. A multiple of several hundred says that a path with a page fault costs several hundred times more than a path without one, under conditions where nearly everything faults. It does not say a real server will run hundreds of times faster.
Caveats that change the reading
XenoSpectrum lists several that the talk itself acknowledged. The DRAM ceiling case had enough capacity for all the data, so the 98 to 99 percent result is not a same-capacity comparison. Price reported an unexplained stall of about 90 milliseconds in memory reclaim, which means the Zswap comparison is not fully valid. And even with swap-ins reduced to zero, at a 20 percent write rate the pressure-stall metric for “memory full” reached 35 to 37 seconds because of direct-reclaim stalls.
Most important, the results do not establish real compression-hardware latency or compression ratios. The tests used DRAM to stand in for the device. The open items listed include the added read latency under direct access, how capacity varies with the data being stored, and whether migration and reclaim can keep pace as write rates climb.
The capacity accounting problem
Tom’s Hardware, working from the published slides, says the talk presents capacity accounting as unsolved. If data compresses well, the machine has more usable memory than its physical size suggests. If the data stops compressing, the machine can run out while the operating system believes it has room. The slides describe a “Chicken Bit” that tells Linux to stop using CRAM while it is busy managing allocations, which prevents what the presentation calls a “poison storm,” a cascade that starts when writes outpace the device’s ability to allocate.
That safety valve prevents a cascade. It does not tell the scheduler how much memory a container can safely be promised. Cloud operators who sell memory by the gigabyte will care about that distinction a great deal.
Status, and what you can use today
CRAM is not in the kernel. XenoSpectrum says its implementation is to be submitted separately from the private NUMA node patch series, whose fifth version was posted on July 20, 2026, and that Price suggested the anonymous-memory-only part would be easiest to upstream first. Phoronix, which first spotted the session, says most of the individual pieces are already mainline and hopes the work lands in the not too distant future.
None of the sources I read name the compression hardware, and none say whether it is CXL-attached. So there is nothing to buy or enable. If you want more effective memory today, ZRAM or Zswap are still the working options. Tom’s Hardware suggests devices such as the Steam Deck that rely on those could eventually benefit, but that is the author’s speculation, not an announced plan.
Frequently asked questions
What is CRAM in Linux?
CRAM is a proposed Linux compressed-RAM service from Meta’s Gregory Price. It manages memory backed by hardware compression as a private NUMA node, with byte-granular reads and read-only mappings, instead of treating it as swap.
How is CRAM different from ZRAM and Zswap?
ZRAM and Zswap work at the swap layer, so reading a compressed page needs a page fault and software decompression. CRAM relies on hardware offload so reads need neither, while writes fault and move the page back to normal DRAM.
Is the 452x speedup real?
It appears in the presentation as a read-only best case measured against ZRAM on a DRAM-based test setup. It does not reflect real compression hardware, and write-heavy cases showed gains of 5.4x to 37x.
Can I use CRAM today?
No. It has not been merged into the Linux kernel, and the sources do not name any compression hardware that supports it.
The interesting part of CRAM is not the benchmark chart. It is the admission, built into the abstract, that a memory device can report a capacity that is partly a promise. Linux has spent decades assuming a page is a page. Hardware compression breaks that, and the proposal is an attempt to teach the memory manager to live with it using parts that already exist. The unanswered questions are the ones that decide whether it matters: what real hardware costs per read, how often real data fails to compress, and who carries the risk when a machine runs out of memory it was told it had. Until a device and a patch series both exist in public, treat CRAM as a well-argued design and not as a feature.
Sources
