On October 5, 2026, Gregory Price of Meta presented the design and test results of "CRAM," a scheme that lets Linux read hardware-compressed memory directly, at the Linux Plumbers Conference 2026 in Prague. With the existing zram and zswap, data that has been swapped out must be decompressed back into regular memory before it can be read. CRAM aims to let applications read data in compressed memory as it is, avoiding the page-fault handling that normally occurs on reads. In the published tests, CRAM reached throughput close to DRAM under certain conditions. However, the performance of the hardware compression itself should be kept separate from the memory-management costs Linux still incurs.
What changes if compressed memory can be read directly
zram and zswap save memory in different ways. According to the official Linux documentation, zram creates a compressed block device in RAM and uses it as swap space or as storage for temporary files. zswap, on the other hand, compresses pages that are about to be swapped out and keeps them in a RAM-based cache. When the cache reaches its limit, older data is written out to the backing swap device.
However, zram used as swap and zswap share some processing on reads. When an application accesses a page that has been swapped out, a "page fault" occurs. Linux allocates a page in regular memory as the destination, restores the compressed data into it, and then resumes execution. If free memory is low, other pages must also be reclaimed to make room for the new one.
The hardware CRAM assumes allows direct access to compressed memory regions at the cache-line or byte level. As a result, pages in compressed memory can remain in the page table, which records the mapping between an application's virtual addresses and physical memory. Because the hardware handles decompression, Linux does not need to bring the entire page back into regular DRAM. The application does not decode the compressed data itself; the hardware presents it as an ordinary memory access.
The differences in the read path are as follows.
| Method | Where and how data is held | What happens when swapped-out data is read |
|---|---|---|
| zram used as swap | Compressed block device in RAM | Handle the page fault and decompress into regular memory |
| zswap | Compressed cache in RAM holding swap pages | Handle the page fault and decompress into an allocated page |
| CRAM design | Directly accessible hardware-compressed memory | Keep a readable mapping; hardware decompresses |
The descriptions of zram and zswap are based on the official documentation, and the description of CRAM is based on Price's talk and the development code. The comparison covers reading pages that have been moved to a compressed region; it does not mean zram behaves the same way when used for file storage. The key point is that CRAM no longer has to allocate a regular-memory page as a decompression target on every read.
Measurements by Kairui Song, which Price showed in his talk, also illustrate this aim. Per-page processing times were about 1.92 microseconds for page-fault handling, about 1.04 microseconds for swap-related management, and about 0.32 microseconds for LZO decompression. This is a separate measurement from the zstd-based comparison tests described below. Even so, it shows that moving compression and decompression into hardware still leaves the costs of page allocation and swap management. CRAM seeks to shorten the entire read path.
Controlling writes and allocation so real capacity is not exceeded
With compressed memory, the capacity visible to the OS does not necessarily match the amount of data the hardware can actually hold. Highly compressible data lets more information fit in less physical memory, but if rewrites worsen the compression ratio, more space is needed to hold the same amount of data. Linux could end up believing it has capacity that the hardware cannot actually support.
Price's design first restricts writes. Pages moved to CRAM are mapped read-only, and if a write occurs, a page fault is triggered and the page is returned to regular DRAM. Reads are served from compressed memory, and only when the content is to be modified is the page moved to regular memory with guaranteed capacity. Without such control, unlimited writes that sharply degrade the compression ratio would outpace memory reclaim.
The route by which pages enter CRAM is also limited. Rather than using CRAM directly every time an application requests new memory, Linux moves pages from regular DRAM to CRAM during memory reclaim. The destination is a "private NUMA node" separated from the normal memory-allocation path.
A NUMA node is a unit Linux uses to manage memory according to its physical location and access characteristics. By excluding the CRAM node from normal allocation targets, the design prevents other kernel processes from inadvertently using compressed memory.
The problem of usable capacity fluctuating with the compression ratio is handled by "ballooning," in which the amount of memory available to the OS is adjusted. In the development code, the device driver notifies CRAM of the compression ratio it is actually achieving and reserves part of the memory accordingly, thereby adjusting the capacity available to Linux.
The driver can also stop accepting new pages. By combining write-protection of pages in compressed memory with a mechanism to halt the inflow of new pages, the design aims to keep capacity shortfalls from spreading even if the compression ratio drops more than expected.
For this reason, one cannot simply look at the compression ratio and conclude that effective RAM capacity will multiply by some factor. Linux and the hardware must jointly manage page read/write permissions, when pages are moved to compressed memory, and capacity adjustment and memory reclaim when the compression ratio changes.
Near-DRAM results must be read alongside the test conditions
The comparison tests Price published carry a note that all measurements used DRAM in order to isolate the cost of page-fault handling. They should therefore not be read as product benchmarks demonstrating the speed of the compression hardware itself or power-saving benefits. What they show is how far software-side processing can be reduced by CRAM's design of keeping pages readable, in a DRAM-based test environment. (Talk slides 11–13)
In the read-only comparison, anonymous memory usage was 46 G and the write rate was 0%. Each method, including CRAM, was given 36 G of physical memory, while the DRAM used as the performance ceiling was given 54 G, enough to hold all the data. Capacity figures use the "G" notation from the talk materials as is.
Results for skewed access and for uniform random access across the entire region are as follows.
| Access distribution | CRAM (million ops/s) | DRAM with sufficient capacity (million ops/s) | CRAM/DRAM |
|---|---|---|---|
| Skewed (Zipf 0.99) | 321 | 325 | About 98.8% |
| Uniform random | 489 | 498 | About 98.2% |
In the read-only tests, CRAM delivered about 98–99% of the throughput of DRAM with ample capacity. The ratios were calculated from the values in slide 11 as 321÷325×100 and 489÷498×100.
However, this is not a comparison against DRAM of the same capacity. The DRAM side was given enough capacity to store all the data and was used as a performance ceiling. Nor does the 98–99% figure guarantee the access latency or compression ratios specific to real compression hardware.
When writes are added, CRAM's throughput falls. Rewriting a page in compressed memory requires handling a page fault and returning the page to regular DRAM. Even so, in the uniform random access tests, with write rates of 2–20%, CRAM's throughput relative to zram ranged from 37 times down to 5.4 times.
The gap in read-only cases and the gap in cases involving writes should not be treated as equivalent, though. In the skewed-access tests, zram was terminated by out-of-memory conditions at write rates of 10% and 20%. All of these are results under the specific test conditions.
Further caution is needed regarding the performance gap with zswap. Price noted that a roughly 90-millisecond memory-reclaim stall of unknown cause occurred, so the zswap measurements are not fully valid. The multiples in that graph alone cannot support a general conclusion that CRAM is several times faster than zswap.
Even when swap-ins drop to zero with CRAM, memory waits do not disappear. In the 20% write-rate test, stalls from direct memory reclaim occurred, and PSI's "memory full" metric, which shows the time tasks were completely stalled waiting for memory, was 35–37 seconds.
Swap-ins and page faults caused by writes are separate processes. How well the benefit of keeping read-heavy data in compressed memory can be exploited depends on the workload's write frequency and on which pages are returned to DRAM.
From anonymous memory to the page cache: implementation work continues
The current development code targets "anonymous memory," such as heap memory with no direct file backing, as well as unmodified file pages. In other words, it also tries to use CRAM for the page cache, which holds file contents in memory.
However, because file pages can be modified through multiple paths, control is more complicated than simply making anonymous memory read-only. An unmodified page can be discarded from memory and read back from the file later. But if the page is to be modified, it must first be returned to regular DRAM.
How much of Linux's existing machinery can be reused is also a focus of development. In the talk description, Price explains that most of the functionality CRAM needs either exists in the current Linux kernel or has been implemented in the past. While it leverages existing features such as write protection via page tables and moving pages between different memory tiers, private NUMA nodes, which allow strict control over allocation targets, are an important foundation for integrating CRAM.
That said, this foundation and CRAM itself are at different stages on the path to kernel integration. The fifth version of the proposal, published on July 20, 2026, presented a mechanism that isolates private memory nodes from normal memory allocation and specifies individually which capabilities, such as reclaim and migration, are permitted. The CRAM implementation itself, meanwhile, is explicitly to be separated from this patch series and submitted on its own.
In a post to the developer mailing list in early September, Price also said he is maintaining a CRAM development branch, and suggested that the portion targeting only anonymous memory would be easier to move forward as an upstream kernel proposal.
The October talk was a forum for discussing what kernel-side mechanisms are needed for Linux to handle compressed memory in a form close to regular memory. It was not an announcement that CRAM has been formally adopted into Linux or that compatible hardware is generally available. Nor can one simply change zram settings on today's PCs to use hardware-compressed memory directly in the same way.
The conditions to verify on real hardware going forward are clear. Measurements are needed on how much read latency increases when compressed memory is accessed directly, and on how usable capacity changes depending on the data's content. Whether page migration to DRAM and memory reclaim can keep up when writes increase will also be important.
If these conditions are met and both compatible hardware and the Linux-side implementation are in place, it may become possible to handle large, read-heavy datasets without bringing pages back into regular DRAM on every access.