noticias

CRAM no Linux promete aproveitar melhor a RAM mas depende de hardware compatível

**Projeto apresentado por engenheiro da Meta busca aproximar o acesso à memória comprimida do desempenho da RAM convencional. A proposta muda o gerenciamento dos dados, mas não aumenta automaticamente a capacidade de qualquer computador.**

A memória RAM pode armazenar mais informações quando os dados são comprimidos.

O desafio é fazer isso sem transformar a economia de espaço em atrasos para os programas.

O projeto **Compressed RAM, conhecido como CRAM**, propõe uma abordagem para o Linux: usar hardware especializado para permitir a leitura de dados comprimidos sem a etapa de descompressão por software exigida por mecanismos tradicionais.

Gregory Price, engenheiro da Meta, apresentou a proposta na Linux Plumbers Conference, em Praga, em 5 de outubro de 2026. Na descrição oficial da apresentação, o desenvolvedor relata desempenho próximo ao da memória convencional em determinados testes. É um resultado promissor, mas que precisa ser entendido dentro das condições avaliadas e da dependência de equipamentos compatíveis.

Para o usuário, a distinção mais importante aparece logo de início: o CRAM não é um aplicativo capaz de transformar qualquer computador com 8 GB de RAM em uma máquina equivalente a outra com 16 GB. A proposta envolve mudanças no gerenciamento de memória do Linux e dispositivos capazes de executar compressão em hardware. O ganho depende tanto dessa infraestrutura quanto do conteúdo armazenado.

O Linux já comprime memória. O que o CRAM muda?

A compressão de memória não começa com o CRAM. O Linux já conta com recursos como **zram e zswap**, que procuram reduzir o impacto da falta de RAM. Eles economizam espaço, mas acrescentam trabalho de processamento para comprimir e recuperar os dados.

O zram cria dispositivos de blocos dentro da própria memória e armazena informações comprimidas. Uma utilização comum é como área de swap, que recebe páginas retiradas da memória de trabalho. O zswap funciona como um cache comprimido antes do dispositivo de swap, reduzindo a necessidade de acessar o armazenamento.

Quando uma aplicação precisa novamente de uma página guardada nesses mecanismos, o sistema deve recuperá-la e descomprimi-la para devolvê-la ao uso normal. Essa operação pode ser vantajosa em comparação com buscar dados em um dispositivo mais lento, mas continua tendo um custo.

O CRAM propõe outra forma de acesso. Com hardware adequado, os dados comprimidos podem permanecer mapeados pelo sistema e ser lidos em pequenas unidades, como bytes e linhas de cache, sem exigir aquela recuperação por software. A descompressão continua fazendo parte do funcionamento do dispositivo; a diferença está em quem realiza o trabalho e em como ele aparece para o sistema operacional.

Isso desloca a discussão da simples economia de espaço para a integração entre hardware e kernel, o núcleo do Linux. O objetivo é aproveitar a compressão mantendo um caminho de leitura mais próximo daquele usado na memória convencional.

Mais capacidade útil não significa mais chips de RAM

A memória comprimida tem uma característica que impede promessas universais: **a quantidade de informação que cabe depende dos próprios dados**. Conteúdos repetitivos podem ser reduzidos com eficiência. Informações difíceis de comprimir oferecem ganhos menores.

Por isso, a capacidade útil não é fixa da mesma maneira que a capacidade física. Um conjunto de dados pode ocupar pouco espaço em determinado momento e passar a exigir mais depois de ser alterado. Para o sistema operacional, isso cria um problema: ele precisa evitar que a memória disponível desapareça justamente quando uma aplicação começa a escrever.

O desenho publicado para o CRAM procura controlar essa situação restringindo a entrada de páginas na região comprimida e usando proteção contra escrita. Quando uma aplicação tenta modificar uma página protegida, o mecanismo pode transferi-la de volta à memória convencional antes de permitir a alteração.

A consequência é uma diferença relevante entre leitura e escrita. Dados consultados repetidamente e modificados pouco tendem a ser candidatos mais favoráveis. Cargas que alteram informações o tempo inteiro podem exigir mais movimentação de páginas, reduzindo a vantagem obtida com a compressão.

O projeto também prevê recuperar espaço quando o dispositivo sinaliza pressão de memória, inclusive recorrendo à swap. A compressão, portanto, não elimina a necessidade de administrar limites: ela acrescenta uma variável ao gerenciamento.

Hardware compatível é parte central da proposta

O CRAM não deve ser confundido com uma nova configuração do zram. O conjunto de propostas publicado por Price inclui exemplos de integração com **Compute Express Link, ou CXL**, tecnologia que permite conectar dispositivos de memória ao sistema.

Essa dependência ajuda a entender por que o projeto pode ter relevância mais imediata em infraestrutura de servidores. Nesses ambientes, operadores conseguem combinar equipamentos específicos, cargas conhecidas e monitoramento contínuo para avaliar se a economia de memória compensa a complexidade adicional.

Para notebooks e computadores domésticos, o caminho é menos direto. Não basta instalar uma distribuição Linux ou atualizar o kernel para obter o benefício descrito. É necessário que o equipamento ofereça os recursos apropriados e que exista suporte completo no sistema.

O material verificado também não permite anunciar uma versão estável do Linux ou uma distribuição que entregue o CRAM como funcionalidade pronta para o público geral. A existência de mecanismos de suporte no kernel não equivale à disponibilidade completa do serviço.

O desempenho apresentado precisa de contexto

Na descrição oficial da apresentação, Price afirma que o CRAM alcança desempenho próximo ao da **DRAM, a memória dinâmica convencional**, nos testes TAOBench e fio. Ele também relata verificações de correção do cache de páginas com a maioria dos sistemas de arquivos presentes no código do kernel.

Essas informações são atribuídas ao responsável pelo projeto. A PixBugTech não executou os testes, e a documentação consultada não estabelece uma reprodução independente suficiente para generalizar os resultados. Desempenho próximo ao da DRAM nas condições avaliadas não representa uma garantia para qualquer programa, dispositivo ou padrão de acesso.

A avaliação prática precisa considerar quanto espaço foi economizado, a frequência das escritas e o custo de transferir páginas entre as diferentes regiões de memória. Também importa observar o comportamento quando os dados deixam de comprimir bem ou quando várias aplicações disputam capacidade simultaneamente.

Uma média favorável pode esconder atrasos pontuais relevantes. Para serviços que precisam responder rapidamente, manter tempos de resposta previsíveis pode ser mais importante do que acomodar um volume maior de dados.

Análise da equipe

A contribuição mais interessante do CRAM é a tentativa de tratar memória comprimida como um recurso integrado ao gerenciamento do Linux, com acesso eficiente e controle sobre sua capacidade variável. A proposta enfrenta um problema concreto: economizar espaço sem fazer cada leitura pagar o custo de recuperar uma página inteira por software.

Nossa avaliação é que os servidores representam o cenário inicial mais plausível para essa arquitetura. Trata-se de uma leitura técnica, não de um anúncio de implantação. Equipamentos especializados e cargas monitoradas permitem medir benefícios e identificar situações em que a movimentação de dados consome a vantagem da compressão.

O interesse da Meta tem um contexto anterior. Em 2022, a empresa descreveu o Transparent Memory Offloading, sistema que transfere dados menos utilizados para recursos como memória comprimida ou SSD. Esse histórico mostra uma busca por administrar diferentes camadas de memória e reduzir a necessidade de RAM em grandes frotas. Os resultados daquele sistema, porém, não devem ser atribuídos ao CRAM.

A possibilidade de economizar memória também não basta para comprovar redução de custos ou consumo de energia. Uma avaliação completa precisa incluir o preço dos dispositivos, seu gasto energético e o trabalho adicional provocado pelas transferências de páginas.

Os próximos sinais relevantes serão a evolução do suporte no kernel, a disponibilidade de hardware e a publicação de testes reproduzíveis com diferentes cargas. Se o CRAM mantiver ganhos quando a compressibilidade dos dados cair e as escritas aumentarem, poderá ampliar as opções de infraestrutura no Linux. Se exigir condições muito específicas, sua utilidade poderá ficar concentrada em aplicações nas quais esse equilíbrio seja favorável.

👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis