Meta está desarrollando una tecnología de compresión de memoria para Linux llamada Compressed RAM (CRAM), capaz de ofrecer un rendimiento casi idéntico al de la memoria DRAM sin comprimir. El ingeniero de la compañía Gregory Price presentó los detalles en la Linux Plumbers Conference de Praga, donde explicó cómo esta solución, al delegar el trabajo de compresión en el hardware, deja atrás a herramientas tan conocidas como ZRAM y Zswap.
La propuesta llega en un momento en que la escasez de memoria y el encarecimiento de los módulos aprietan a toda la industria, mientras las necesidades de capacidad siguen creciendo sin pausa. CRAM permite acceder a los datos comprimidos a nivel de línea de caché o de byte, algo que ninguna de las soluciones actuales por software consigue sin penalizar el rendimiento del sistema.
Así funciona la compresión de memoria por hardware de Meta
El punto de partida de CRAM es sencillo de entender aunque su implementación no lo sea: en vez de pedirle a la CPU que comprima y descomprima datos cada vez que el sistema necesita acceder a ellos, esa tarea se delega directamente al hardware. El procesador puede entonces leer o escribir en la memoria comprimida como si estuviera trabajando con memoria normal, sin pasos intermedios que frenen el proceso.
Este acceso a nivel de línea de caché o byte es lo que marca la diferencia. Las soluciones que conocemos hasta ahora trabajan con bloques completos de datos que hay que descomprimir antes de usarlos, lo que introduce latencia. Al eliminar ese paso, Meta consigue que buena parte del trabajo pesado desaparezca del camino crítico, y de ahí que los resultados mostrados en Praga se acerquen tanto a los de la memoria sin comprimir.
Qué cambia frente a ZRAM y Zswap en Linux
Si trabajáis con Linux es probable que ya conozcáis ZRAM y Zswap, dos piezas del kernel pensadas para estirar la memoria disponible. ZRAM crea un dispositivo de bloques comprimido dentro de la propia RAM y lo usa como espacio de intercambio; Zswap, por su parte, actúa como una caché comprimida que intercepta las páginas antes de que lleguen al disco. Ambas funcionan bien, pero dependen por completo de la CPU para comprimir y descomprimir, y esa carga se nota cuando la memoria empieza a apretar de verdad.
CRAM parte de la misma necesidad (aprovechar mejor cada byte de RAM física) pero cambia quién hace el trabajo. Al apoyarse en hardware dedicado, evita la sobrecarga de procesador que arrastran ZRAM y Zswap. Por eso Meta lo presenta como una implementación superior: no se trata de un ajuste fino sobre lo que ya existe, sino de resolver el problema desde otro ángulo.
Los resultados vistos en la Linux Plumbers Conference
Los datos que Price expuso en Praga son llamativos. Para las operaciones de lectura sobre datos ya comprimidos, CRAM alcanza una velocidad prácticamente igual a la de la memoria DRAM sin comprimir, lo que en la práctica elimina la penalización que suele asociarse a trabajar con memoria comprimida. Ese resultado implica que, en la práctica, no debería notarse diferencia entre trabajar con datos comprimidos por CRAM y hacerlo directamente sobre memoria sin comprimir, algo que ninguna de las soluciones basadas en software había logrado hasta ahora.
En las escrituras, donde ZRAM y Zswap suelen notarse más, CRAM también sale ganando: es mucho más rápido que ambas alternativas, e incluso que el intercambio convencional a disco. Meta no ha publicado cifras exactas en porcentaje, pero la diferencia frente al intercambio convencional a disco se describe como sustancial, lo que refuerza el atractivo de CRAM en los escenarios donde la memoria física se agota con rapidez.
El camino que le queda a CRAM antes de llegar al kernel
La buena noticia para quienes sigan de cerca el desarrollo del kernel es que la mayoría de las piezas necesarias para soportar CRAM ya forman parte de la rama principal de Linux. Eso reduce bastante el trabajo que queda por hacer antes de que esta tecnología pueda integrarse de forma completa, aunque de momento no se ha concretado un calendario ni una versión del kernel en la que esperar su llegada.
Conviene ser prudentes con los plazos. Al depender de la delegación de procesamiento en el hardware, es previsible que CRAM necesite controladores y módulos de memoria compatibles, un requisito que podría tardar más en generalizarse en los equipos domésticos que en los entornos de servidor, donde Meta ya opera a gran escala. Mientras ese soporte no se confirme para el hardware de consumo, lo más razonable es asumir que ZRAM y Zswap seguirán siendo las herramientas de referencia para quienes usan Linux en sus ordenadores personales.