El 5 de octubre de 2026, Gregory Price, ingeniero de Meta, presentó en Linux Plumbers Conference un servicio de memoria comprimida en desarrollo llamado Compressed RAM (CRAM). La implementación probada se identifica como mm/cram.c y plantea una diferencia clave frente a la compresión de memoria convencional: delegar la compresión al hardware y conservar el acceso directo a los datos. La sesión de la conferencia describe el diseño y los resultados comunicados.
Cómo se describe el acceso a la memoria comprimida
CRAM está diseñado para que los datos comprimidos sigan siendo accesibles a nivel de byte y de línea de caché. Según la descripción de la sesión, esa memoria puede permanecer mapeada en las tablas de páginas —las estructuras que conectan las direcciones de un programa con la memoria— y en la caché de páginas, sin provocar fallos de acceso al leer ni requerir descompresión por software en cada lectura.
El contraste de la presentación con ZRAM y Zswap se centra en ese modelo de acceso. CRAM desplaza la compresión al hardware; la descripción no plantea simplemente otro algoritmo de compresión por software.
Qué resultados de rendimiento se comunicaron
El resumen de la sesión afirma que la implementación probada alcanzó un rendimiento cercano al de DRAM en TAOBench y FIO, dos herramientas de pruebas de rendimiento. También indica que se comprobó la corrección de la caché de páginas con la mayoría de los sistemas de archivos incluidos en el árbol del kernel.
En las pruebas de lectura de datos de solo lectura, la presentación comunicó un rendimiento a la velocidad de DRAM. La comparación de lectura con Zswap estaba afectada por un atasco durante la recuperación de memoria (reclaim), una advertencia que limita la lectura de ese resultado.
Una diapositiva sobre escrituras presentó una ventaja de entre 5 y 37 veces frente a ZRAM en los casos mostrados. Incluía cargas de trabajo sesgadas, con distribución Zipf de 0,99, y aleatorias uniformes, descritas como el peor caso. Esas cifras corresponden a los escenarios concretos de la diapositiva.
Las piezas de gestión de memoria que necesita
El resumen de la sesión enumera como requisitos el soporte de memoria anónima, la caché de páginas, la recuperación y migración de páginas, el memory ballooning, el informe de páginas libres, la jerarquización de memoria y la asignación NUMA controlada. La arquitectura NUMA distribuye la memoria entre nodos con distintas relaciones de proximidad a los procesadores.
Según ese resumen, todas salvo una de las funciones necesarias existen en el kernel o existieron en algún momento. La lista reúne áreas de gestión de memoria que el servicio necesita para funcionar junto a las tareas habituales de Linux.
