Em 5 de outubro de 2026, Gregory Price, engenheiro da Meta, apresentou na Linux Plumbers Conference, em Praga, uma implementação testada do Compressed RAM (CRAM), serviço de memória comprimida para Linux identificado como mm/cram.c. O projeto delega a compressão ao hardware e foi descrito para manter acesso direto aos dados comprimidos, em vez de tratá-los apenas como páginas de swap.

O que a Meta apresentou para Linux

O CRAM está em desenvolvimento. Na apresentação, Price descreveu um serviço que combina memória comprimida com acesso por linha de cache — um bloco transferido entre memória e processador — e por byte. A proposta também mantém a memória mapeada nas tabelas de páginas e presente no cache de páginas, a área que conserva dados de arquivos usados pelo kernel.

Esse modelo, conforme descrito por Price, permite acessar os dados sem gerar uma falha de leitura de página nem exigir uma etapa de descompressão por software a cada acesso. É essa combinação de compressão delegada ao hardware e acesso semelhante ao da memória convencional que diferencia a abordagem apresentada de ZRAM e Zswap.

O que os resultados relatados abrangem

Price relatou desempenho próximo ao da DRAM nos testes TAOBench e FIO. Também descreveu testes de correção do cache de páginas em grande parte dos sistemas de arquivos integrados ao kernel. Esses resultados dizem respeito à implementação testada do serviço.

Nos gráficos apresentados, a leitura de dados somente de leitura apareceu no nível da DRAM. Um slide resumiu os casos de escrita exibidos como taxas de transferência de 5 a 37 vezes as do ZRAM, em cargas enviesadas (Zipf 0,99) e em cargas aleatórias uniformes, indicadas como o pior caso. O intervalo se refere a esses cenários de escrita; não é uma medida geral para qualquer carga.

A apresentação também indicou escritas mais rápidas que ZRAM, Zswap e swap em disco. Já o gráfico de leitura assinalava um problema de reclaim-stall nos resultados do Zswap, uma condição que afeta a comparação exibida.

As áreas do kernel envolvidas

O suporte necessário ao CRAM abrange memória anônima — não vinculada diretamente a um arquivo —, cache de páginas, recuperação e movimentação de páginas entre níveis de memória, ballooning, relatório de páginas livres, organização da memória em níveis e alocação NUMA controlada. NUMA é uma arquitetura em que a latência de acesso à memória varia conforme sua proximidade dos processadores.

Price afirmou que todos, menos um, dos recursos necessários já existem no kernel ou existiram em algum momento.