10 Oct 2026 · memory, linux, performance · 4 min
Compressing memory in hardware, against zstd in software
A single pass of zstd at level 1 over 96 MB of binaries takes under half a second. At level 9, the same data takes 3.1 seconds. Going by those two numbers alone, compressing memory looks like a volume knob: you pick how slow you want to be. The question moved in October, when Meta brought a proposal to compress RAM in hardware to the Linux Plumbers Conference. They call it CRAM.
What the proposal changes
zram and zswap have done this in software for years. Both work page by page, 4 KB at a time, and every compressed page costs a round trip to the processor. When memory runs short, that cost lands at the worst possible moment, exactly when the system needs to be fast.
CRAM takes that cost out of the way by compressing larger blocks and pushing decompression into hardware, so compressed memory behaves more like memory and less like swap. The talk material is on the event site and the technical summary is at Phoronix.
What software gives you today
Before waiting on hardware, it helps to know the baseline. I took 96 MB of real files, the shared binaries of a Linux system, and timed zstd at three levels, compressing and decompressing:
| level | compress | decompress | ratio |
|---|---|---|---|
| 1 | 211.3 MB/s | 652.5 MB/s | 2.30x |
| 3 | 145.6 MB/s | 596.7 MB/s | 2.52x |
| 9 | 30.7 MB/s | 549.7 MB/s | 2.73x |
Decompression barely moves with the level, and that is the useful part. The price of compressing better is paid on the way in, not on the way out. The ratio also only climbs from 2.30x to 2.73x while compression speed drops sevenfold. That is an honest argument for compressing fast instead of compressing perfectly.
Scaled to 3.8 GB of memory, the size of a small machine today:
level 1: compress 18.1 s | decompress 5.9 s
level 3: compress 26.3 s | decompress 6.4 s
level 9: compress 124.8 s | decompress 7.0 s
One full compression pass over 3.8 GB costs between 18 seconds and two minutes. Handing it all back decompressed costs 6 seconds, and level 9 does not make that worse. Under pressure, the second number is the one that matters, and it is good.
Why blocks beat pages
One engineering detail explains the proposal. A 4 KB page is too small for a compressor to find patterns: the dictionary is short and the ratio stays low. Grouping pages into a larger block gives the compressor more repetition to work with, at the cost of needing the whole block whenever any part of it is read. That is the trade hardware is meant to solve, because decompressing large blocks in software is expensive at every level.
Where the math bends
One run per level, measured in blocks. The kernel compresses page by page under reclaim rather than in blocks, so treat the figure as an order of magnitude. Binaries also compress better than the average memory page because they carry a lot of repeated code, so a whole system usually lands below that 2.30x.
The gap between 2.30x and 2.73x is worth naming out loud, because it is the whole argument of the CRAM talk. If the same memory compresses just 19 percent better when you spend seven times more CPU, the interesting question is not how much better software can get. It is why we are still paying CPU for this at all.
If CRAM ships, the win will not be the compression ratio, which software already delivers, but not spending a CPU core to get it. Anyone running a tight machine should do what I would do today: compress fast, decompress without worry, and accept a lower ratio. It is less elegant than dedicated silicon and it solves this year’s problem.
Two earlier posts in this blog run into the same wall: swap is not free RAM showed what happens when memory really runs out, and a measurement of software compression showed what zram delivers in practice. CRAM is a bet that there is a better way to do the same job.