Linux LZ4: ressincronização para v1.10.0 acelera a descompressão em até 21%

O engenheiro da Samsung Michal Wilczynski publicou em 25 de setembro de 2026 uma série de 9 patches. A série atualiza o código de compressão LZ4 do kernel Linux para a versão upstream LZ4 v1.10.0. A cópia do kernel está 488 commits atrás do upstream. A atualização acelera a descompressão em todos os tamanhos de bloco testados, em até 21%. Ela também fecha uma brecha de segurança no código antigo.

LZ4 é um formato de compressão feito para velocidade, e não para arquivos pequenos. O kernel o usa onde os dados precisam ser compactados e descompactados o tempo todo. Exemplos são a memória comprimida e os sistemas de arquivos somente leitura.

Quão atrasado está o LZ4 do kernel

O kernel não carrega o LZ4 como uma biblioteca externa. Ele mantém sua própria cópia do código na árvore de fontes, e essa cópia se desviou. Segundo a carta de apresentação de Wilczynski, as duas metades estão congeladas em pontos diferentes.

Parte	Versão no kernel	De
Descompressor	LZ4 v1.8.3	2018
Compressor	LZ4 v1.7.3	2017
Alvo upstream	LZ4 v1.10.0	22 de julho de 2024

O projeto upstream lançou a v1.10.0 em 22 de julho de 2024 e a chamou de "Multicores edition". As notas de versão dizem que ela reúne mais de 600 commits. O principal recurso é a compressão multithread. Ela também promove a compressão por dicionário a estável.

O problema das verificações de limites

O argumento mais forte da carta de apresentação é sobre segurança, não velocidade. A função LZ4_decompress_fast() bifurcada do kernel nunca verifica se está escrevendo dentro do seu buffer. "O LZ4_decompress_fast() bifurcado não tem verificações de limites, então uma entrada corrompida ultrapassa o buffer de saída nas duas direções", escreveu Wilczynski.

Uma verificação de limites é um teste que impede o código de ler ou escrever além do fim de um bloco de memória. Sem ela, dados comprimidos danificados ou maliciosos podem fazer o descompressor sobrescrever memória não relacionada. Esse é o caminho clássico para uma falha ou uma brecha de segurança. A ressincronização substitui o código bifurcado pela versão do upstream.

A troca entre velocidade e tamanho

A carta de apresentação relata descompressão mais rápida em todos os tamanhos de bloco testados, de 4K a 256K. Os ganhos para a própria biblioteca LZ4 foram:

• Blocos de 4K: 11% mais rápido
• Blocos de 16K: 21% mais rápido, o maior ganho
• Blocos de 64K: 17% mais rápido
• Blocos de 256K: 10% mais rápido

Testes pelo EROFS, um sistema de arquivos somente leitura, mostraram 11% com 4K e 14% com 64K.

O custo é o tamanho. No x86_64, o código compilado cresce de 45K para 89K. A carta de apresentação atribui a maior parte disso ao parser mais completo do upstream.

A série também muda a forma como o código é mantido. O kernel passaria a carregar os arquivos do upstream como são, em vez de um fork editado à mão. "Uma ressincronização vira uma cópia de diretório", escreveu Wilczynski.

O que isso significa para desenvolvedores

Verifique primeiro se você usa LZ4 no kernel. A carta de apresentação cita quatro usuários: zram, erofs, f2fs e lib/decompress_unlz4. O zram é um dispositivo de swap comprimido que fica na RAM. O EROFS é um sistema de arquivos somente leitura, e o F2FS é um sistema de arquivos projetado para armazenamento flash.

Se você usa zram com LZ4, esta é a mudança com mais chance de chegar até você. O swap para o zram acontece sob pressão de memória, quando cada ciclo de CPU conta. Um ganho de dois dígitos na descompressão pode aparecer ali como um sistema mais responsivo. Execute cat /sys/block/zram0/comp_algorithm para ver qual algoritmo o seu dispositivo zram usa.

Se você distribui imagens em EROFS, o ganho de 11-14% se aplica à leitura de arquivos. Isso provavelmente importa mais quando muitos blocos pequenos são lidos de uma vez, como na inicialização. Faça benchmarks no seu próprio hardware antes de contar com isso. Os números da carta de apresentação vêm da própria configuração de testes dela.

Se você compila para dispositivos muito pequenos, observe o aumento de 44K no tamanho do código. Em um kernel embarcado com orçamento de flash apertado, vale a pena medir.

Trate a correção das verificações de limites como o verdadeiro motivo para querer esta mudança. Qualquer caminho que descomprima dados do disco ou da rede com o antigo decodificador rápido confia totalmente na sua entrada. Até a série ser integrada, prefira as funções de descompressão com verificação no seu próprio código do kernel.

Esta é uma série de patches em revisão, não código mesclado. Acompanhe a lista linux-kernel para ver as respostas dos mantenedores. São elas que vão decidir quando a série chega a uma versão.