Linux CRAM keeps compressed memory in RAM, claims up to 452x ZRAM read performance

A compression path that skips swap

Tom's Hardware has reported on a new Linux memory compression approach called CRAM, which takes aim at one of the oldest assumptions in kernel memory management: that compressed pages should be handled as swap. Instead, CRAM keeps compressed data in RAM as ordinary memory, and according to the report it delivers up to 452 times the performance of ZRAM for compressed memory reads. The story, published on October 7, subsequently reached the front page of Hacker News.

Where zswap and ZRAM fall short

Memory compression is not a new idea in Linux. As Tom's Hardware points out, the two most widely used mechanisms are zswap and ZRAM, and both are fundamentally swap-layer features. ZRAM presents a compressed block device in RAM that the kernel treats as a swap target; zswap sits as a compressed cache in front of a conventional disk-backed swap device. In either case, compressed pages are managed through the swap subsystem, which means access to them follows swap code paths even though the backing store never leaves memory.

CRAM's pitch is to remove that indirection. By keeping the compressed data in RAM and treating it as RAM rather than as swap entries, reads of compressed pages can take a much more direct route. The reported result is the headline figure: up to 452x the performance of ZRAM.

The intuition behind the design is decades old. The report's author recalls wondering, back in the PKZIP era of the 1990s, why memory could not be compressed the way files were, and notes that many others had the same thought. That line of thinking is why most operating systems have shipped some form of memory compression for a long time.

Reading the 452x claim carefully

The figure deserves scrutiny. It is an "up to" number, which typically represents a best-case measurement rather than an average across workloads. How much of the speedup survives in everyday use will depend on access patterns, compression ratios, and how much of a workload's memory actually sits in compressed pages. The coverage so far does not include independent benchmarks, so the claim reflects the project's own positioning until third-party testing appears.

Why it matters

If CRAM holds up, the practical consequences reach beyond raw benchmark numbers. Systems under memory pressure, such as laptops with modest RAM, virtual machines, containers, and embedded devices, rely on compression to avoid the much heavier cost of disk swap. Making reads from compressed memory dramatically cheaper would let the kernel keep more effective capacity without the latency penalty that swap-based approaches impose, and could reduce reliance on disk swap altogether, with attendant benefits for storage wear.

Just as significant is the design point itself. The swap-centric model has shaped Linux memory compression for years, and a credible alternative that treats compressed pages as first-class memory would reopen a corner of the kernel that has seen little fundamental change. Whether CRAM becomes mainstream or remains a niche technique, the discussion it has started, and the scrutiny of that 452x figure, are likely to continue.