10 out 2026 · memória, linux, desempenho · 4 min

Comprimir memória no hardware, contra o zstd em software

Uma passada do zstd no nível 1 sobre 96 MB de binários leva menos de meio segundo. No nível 9, o mesmo dado leva 3,1 segundos. Olhando só esses dois números, comprimir memória parece decisão de botão de volume: você escolhe o quanto quer ficar lento. A conversa mudou de lugar em outubro, quando a Meta levou para a Linux Plumbers Conference uma proposta de comprimir memória RAM no hardware, chamada CRAM.

O que a proposta muda

O zram e o zswap já fazem isso em software há anos. Os dois trabalham página por página, 4 KB de cada vez, e cada página comprimida custa ida e volta ao processador. Com memória apertada, esse custo aparece na hora errada: quando o sistema precisa estar rápido.

A ideia do CRAM é tirar essa conta do caminho, comprimindo blocos maiores e devolvendo a descompressão para o hardware, de modo que a memória comprimida se comporte mais como memória e menos como área de troca. O material da apresentação está no site do evento e o resumo técnico ficou no Phoronix.

O que o software entrega hoje

Antes de esperar hardware, vale saber a régua do que já existe. Peguei 96 MB de arquivos reais, os binários compartilhados de um sistema Linux, e cronometrei o zstd em três níveis, comprimindo e descomprimindo:

A descompressão quase não muda com o nível. Essa é a informação útil: o preço de comprimir melhor é pago na entrada, não na saída. E a razão sobe pouco, de 2,30x para 2,73x, enquanto a velocidade de compressão cai sete vezes. Um argumento honesto a favor de comprimir rápido em vez de comprimir perfeito.

Traduzindo para uma memória de 3,8 GB, o tamanho de uma máquina pequena hoje:

nível 1: comprimir 18,1 s | descomprimir 5,9 s
nível 3: comprimir 26,3 s | descomprimir 6,4 s
nível 9: comprimir 124,8 s | descomprimir 7,0 s

Uma passada completa de compressão sobre 3,8 GB custa de 18 segundos a dois minutos. Devolver tudo descomprimido custa 6 segundos, e não piora no nível 9. Em situação de aperto o número que importa é o segundo, e ele é bom.

Por que o bloco ganha da página

Existe um detalhe de engenharia que explica a proposta. Página de 4 KB é pequena demais para um compressor encontrar padrão: o dicionário é curto e a razão fica baixa. Juntando várias páginas em um bloco maior, o compressor enxerga mais repetição e comprime melhor, ao custo de precisar do bloco inteiro na hora de descomprimir qualquer pedaço dele. É a troca que o hardware vem resolver, porque descomprimir bloco grande em software custa caro em qualquer nível.

As bordas da conta

Foi uma rodada por nível, medida em bloco. O kernel comprime página por página sob pressão, não em bloco, então o valor serve como ordem de grandeza. Binários também comprimem melhor que a média das páginas da memória, porque têm muito código repetido: a razão real de um sistema inteiro tende a ser menor que esses 2,30x.

Se o CRAM vingar, o ganho não vai estar na razão de compressão, que o software já resolve, e sim em não gastar núcleo de processador para conseguir essa razão. Quem opera máquina apertada faz o que eu faria hoje: comprime rápido, descomprime sem medo, e aceita razão menor. É menos elegante que uma peça dedicada de hardware e resolve o problema deste ano.

Quem já acompanha o assunto por aqui sabe onde isso encosta: swap não é RAM grátis mostrou o que acontece quando a memória acaba de verdade, e uma medição de compressão em software mostrou o que o zram entrega na prática. O CRAM é a aposta de que existe um jeito melhor de fazer a mesma coisa.