News from the IT community on October 8th: Engineers from Meta presented an experimental memory compression solution named CRAM at the Linux Plumbers Conference 2026 ( LPC 2026) event held in Prague, Czech Republic, on October 5th.
The goal of this solution is not simply to replace ZRAM or zswap, but rather to allow the compressed data to continue to exist in the form of "memory," thereby avoiding the software overhead associated with the traditional Swap path. Official LPC documentation indicates that CRAM has already completed actual testing and can achieve performance close to that of the native DRAM in the TAOBench and FIO benchmark tests.
As is well known, the common memory compression schemes for Linux currently include ZRAM and zswap. ZRAM creates compressed block devices in memory, and the kernel needs to process the data within them according to the Swap path; however, CRAM is designed differently. Compressed data can still maintain page table mappings and page cache states, and it supports Cacheline and Byte level access. Therefore, when reading data, there is no need to trigger a software decompression process through a page fault exception as with traditional schemes. LPC official documentation states that this is also a key feature that distinguishes CRAM from ZRAM and zswap.
The core idea of CRAM is to provide the compressed hardware memory as a special type of NUMA memory to Linux, rather than simulating it as a block storage device.
According to the information, CRAM utilizes a strictly controlled private NUMA node, which allows the kernel to continue using the existing memory management mechanisms, including memory migration, recycling, downgrading, the memory balloon mechanism, free page reporting, and NUMA memory balancing, among others.
This design is aimed at addressing the software path overhead in traditional memory compression schemes. For read-only data, CRAM can be directly read from the compressed memory without the need to first transfer the data to regular memory and then decompress it. In this mode, the performance of CRAM can approach that of the native DRAM.
According to the test data disclosed in this demonstration, in a pure read scenario, CRAM can achieve approximately 489 million operations per second in the worst-case scenario, while ZRAM can perform about 1.1 million operations per second. Based on these figures, the difference between the two is about 444 times, not 452 times. Therefore, the official claim of a "452-fold improvement" may only be achievable in an ideal environment.
When the workload includes write operations, the advantages of CRAM become significantly reduced. Since compressed data cannot be modified in place, during writing, it is necessary to use page-out processing to migrate the corresponding Folio back to the native NUMA node before making any modifications.
Even so, in the worst-case scenario described in the material, CRAM still achieves approximately 5.4 times the performance of ZRAM. However, this figure should also be understood as a result of a specific benchmark test, rather than a general conclusion regarding performance.
According to official information, CRAM is still in the stage of a tested kernel service prototype and has not yet become a mature feature part of the Linux mainline.
An engineer, as mentioned by Gregory Price, stated that most of the kernel fundamental mechanisms required to implement CRAM already exist. What needs to be further addressed at present is how to make memory devices with "inconsistent actual capacity and physical capacity" comply with Linux's existing memory model.
IT Home Reminder: Currently, CRAM is still in the research and development and community discussion phase and cannot yet be considered a formal feature set to be integrated into the mainline of Linux. The focus of this public release is to explore how to utilize the existing Linux memory management mechanism to support this new type of compressed memory, rather than to announce a product that has already undergone standardization or commercial deployment.
