Memory compression on Linux usually means zswap or ZRAM – both implemented at the swap layer, with page faults, block I/O semantics and software decompression. At Linux Plumbers Conference 2024, Gregory Price from Meta presented a different approach: CRAM (Compressed RAM service).
What is CRAM?
CRAM effectively asks: “What if we did ZRAM entirely in RAM, without swap?” Instead of pretending to be a block device, CRAM exposes compressed memory as a private NUMA node, i.e. a “ghost CPU” domain the kernel can manage with its existing memory machinery.
From the LPC talk and slides, CRAM:
- Provides cacheline / byte-granular access to compressed memory
- Keeps pages mapped in page tables and present in the page cache without read faults or software decompression
- Achieves near‑DRAM performance under TAOBench and FIO benchmarks
- Reuses existing kernel features: page-table write protection (COW, KSM) for anonymous memory, Clean Cache for page cache, reclaim & demotion, memory ballooning, free page reporting, and memory tiering
Because compressed data actually lives in RAM and is accessed directly, the main overhead is the hardware-offloaded compression, not page faults or swap behavior. In the LPC slides, a read‑only workload shows CRAM handling about 489M ops/s vs. ZRAM’s 1.1M ops/s – roughly 452× faster. With 20% writes enabled, it’s still about 5.4× faster than ZRAM.
The big drop when writes enter the picture comes from the need to page fault and migrate folios back to the original NUMA domain: you can’t safely write in‑place to compressed data without corrupting it.
The hard problem: how much RAM do you really have?
Compressed RAM sounds easy until you ask: “How much logical memory does this actually represent?” Compressibility varies wildly, from all‑zero pages (ideal) to already‑compressed media (worst case). The LPC abstract is explicit: this is still an open research problem.
To avoid catastrophic behavior when allocations outpace what CRAM can actually back, the design includes a “Chicken Bit”: a control flag that tells the kernel to stop trying to use CRAM while it’s busy managing allocations, preventing the “poison storm” of cascading failures mentioned in the talk.
Why it matters beyond hyperscale servers
Given its origin at Meta, the primary target is clearly large Linux servers. But zswap and ZRAM are used across the Linux ecosystem – even on constrained devices like the Steam Deck and many ARM SBCs, where distributions often enable one of them by default.
If CRAM’s design makes it into mainline Linux and the remaining accounting issues are solved, embedded boards, SBCs and low‑RAM systems could see:
- Higher effective memory capacity without disk‑backed swap
- Much faster read‑heavy workloads compared to ZRAM
- Better integration with existing NUMA, migration, and ballooning logic
For makers and embedded developers, that could eventually mean more headroom for containers, browsers, and heavy services on tiny Linux boxes – with fewer compromises on performance.
Source: Linux Plumbers Conference, Tom's Hardware
