Meta's new Linux solution compresses memory 452x? Meta engineers pitched a new solution at the Linux Plumbers Conference 2026 called CRAM, short for Compressed RAM. The official abstract is quite restrained: under TAOBench and FIO benchmarks, it achieved near-native

💡 What You Will Learn

Meta's new Linux solution compresses memory 452x? Meta engineers pitched a new solution at the Linux Plumbers Conference 2026 called CRAM, short for Compressed RAM. The official abstract is quite rest

📜 Table of Contents

• What the 452x Actually Eliminates
• Writes Fall Apart on Contact
• The Bottleneck Was Never Compression
• Three Reasons You Can't Use This Now

Meta's New Linux Approach Compresses Memory 452x?

Meta engineers pitched a new approach at Linux Plumbers Conference 2026 called CRAM, short for Compressed RAM. The official abstract is restrained: under TAOBench and FIO benchmarks, it achieves performance close to native DRAM.

But what really went viral was another number: 489 million read throughput per second, versus ZRAM's 1.1 million per second — a 452x difference.

The number is real. The problem is, it doesn't represent what you feel when you open a program.

What the 452x Actually Eliminates

The core of CRAM is that it stops disguising compressed memory as a block device. The Linux kernel has a long-standing assumption: as long as you can produce a struct page, there's real physical memory behind it. But compressed memory devices can't do this — they lie to the kernel about their actual capacity, because how much logical memory fits into a given space after compression depends on how well the data itself compresses.

Gregory Price's solution sidesteps this contradiction: build a private NUMA node for compressed memory, making it look like memory attached to a "shadow CPU." This way the kernel can manage it directly using its own memory management machinery, hardware decompresses on the fly during reads, and there are no page faults throughout. ZRAM and zswap, by contrast, are built on the swap layer — when a program wants to read a compressed chunk of data, it has to trigger a page fault first, pull it out of the virtual block device, decompress it, and then hand it to the program.

So the 452x eliminates software-layer overhead, not the compute cost of compression itself.

Writes Fall Apart on Contact

The author of that article flagged an easily overlooked detail on the performance chart: it's on a logarithmic scale. In other words, the 452x magnitude is already "barely comparable" on that chart.

What really stands out is another set of numbers. At low write rates, CRAM is roughly 37x ZRAM; once the write ratio climbs to 20%, the advantage collapses to 5.4x. From 452 to 5.4 — that's a gap of over eighty times. This isn't performance degradation; it's a different race entirely.

The reason is straightforward: compressed data can't be modified in place. To change a single byte, you have to modify the entire compressed page, so every write triggers a page fault, migrates that page back to native DRAM, and then runs through the compression pipeline again.

This means the 452x only holds in read-heavy, write-light scenarios: large-scale data scanning, model inference reading weights, read-only config loading. Workloads that frequently modify memory — databases, compilers, browser tabs — get zero benefit. And the 20% write test included stall periods caused by memory being fully saturated, so the 5.4x figure is already on the optimistic side.

The Bottleneck Was Never Compression

Gregory Price offered harder evidence in his talk. He had someone actually measure how long it takes to read a single compressed page, and the breakdown looked like this:

In the best case, decompression costs less than 10% of a single swap page fault. In other words, compression was never the bottleneck — page faults were.

We default to assuming "slow memory compression = compression algorithm burning CPU," but what actually stalls the system is interrupts, context switches, and memory copying. And that's exactly why an approach that doesn't touch the compression algorithm at all — only the memory management model — can achieve hundreds of times improvement.

Price's implementation is simpler than you'd think. He didn't build a new memory subsystem; he built a private NUMA node for compressed memory, making it look like memory attached to a "shadow CPU," then directly reused the kernel's existing page migration, memory ballooning, and memory tiering mechanisms. He also added a switch called "Chicken Bit": once CRAM can't keep up, the kernel stops feeding it new allocations, avoiding cascading failures when write speed can't keep pace.

Three Reasons You Can't Use This Now

First, there's no hardware. CRAM depends on memory devices with hardware compression — the most likely real-world platform being CXL memory expanders with inline compression. Your laptop and desktop don't have this.

Second, it's not in the kernel. mm/cram.c is currently just a proposal awaiting upstream review, with no timeline.

Third, capacity is unpredictable. Compression ratios fluctuate wildly with workload, and the capacity a device reports doesn't match how much logical memory it can actually hold. Someone at the talk asked on the spot: if you allocate based on a 4:1 compression ratio but the workload is read-only, would the result be worse? Someone else pointed out that the global target compression ratio is actually closer to 2.5x than 4x. These questions went unanswered by the end of the talk, and Price himself said it hasn't been run on real hardware yet.

Those three points together are enough to make most people scroll past. But server memory being expensive is a real problem — adding DRAM to machines is a genuine hardware expense, which is why this approach came out of Meta.

For individual users, CRAM isn't an option today. If you're being tortured by insufficient memory, studying your system's built-in compressed memory strategy is more practical.

What that Meta engineer did was re-ask a question everyone thought was already answered: what's actually slow — the compression, or everything around it?