Last week, I happened to go through a slide deck by Gregory Price of Meta about CRAM, presented at the Linux Plumbers Conference. It’s good stuff. With RAM prices rising, I think the idea is worth understanding.
From fundamentals first. Linux already uses kernel modules zram & zswap that compress less-used blocks of memory called pages. A 4 KiB page might shrink to 1 KiB. That’s 3 KiB saved, letting you store more in the same RAM. But when an application needs it again, it triggers a page fault. Linux pauses the app, decompresses the page and restores access. Repeating this costs time.
Now CRAM asks a simple question. What if the CPU could read that page without Linux first unpacking it? The idea is to put compression and decompression inside the memory hardware. Data stays compressed in RAM, but when the CPU requests it, the hardware returns the original bytes automatically. Applications still use normal memory addresses. Linux doesn’t need to swap the page back in just for a read. This could be especially useful for data you read often but rarely change.
Writes are harder. Our 1 KiB compressed page might expand to nearly 4 KiB if you replace its contents with data that won’t compress. CRAM handles this by keeping compressed pages read-only. A write triggers a move back to ordinary RAM before the change is made. So the benefit depends on the workload. His work reported a 452x throughput gain over zram. But the test used DRAM-backed memory to isolate page-fault overhead. It doesn’t prove 452x faster applications on real compressed hardware.
I think the question is whether this can scale. With RAM prices rising, saving physical memory could matter for servers. But it’s no magic bullet. CRAM needs compression-capable hardware, making widespread use a next-generation change rather than a software update. The approach isn’t limited to Linux either. Will hardware makers and OS developers, including Microsoft, see value in adopting it? I really hope they do.
0 Comments