Linux LZ4: la resincronización a v1.10.0 acelera la descompresión hasta un 21%

El ingeniero de Samsung Michal Wilczynski publicó el 25 de septiembre de 2026 una serie de 9 parches. La serie pone al día el código de compresión LZ4 del kernel Linux con la versión upstream LZ4 v1.10.0. La copia del kernel va 488 commits por detrás de upstream. La actualización acelera la descompresión en todos los tamaños de bloque probados, hasta un 21%. Además, cierra un hueco de seguridad en el código antiguo.

LZ4 es un formato de compresión pensado para la velocidad más que para archivos pequeños. El kernel lo usa donde los datos se deben comprimir y descomprimir constantemente. Algunos ejemplos son la memoria comprimida y los sistemas de archivos de solo lectura.

Cuánto se ha quedado atrás el LZ4 del kernel

El kernel no carga LZ4 como una biblioteca externa. Lleva su propia copia del código en su árbol de fuentes, y esa copia se ha ido desviando. Según la carta de presentación de Wilczynski, las dos mitades están congeladas en puntos distintos.

Parte	Versión en el kernel	De
Descompresor	LZ4 v1.8.3	2018
Compresor	LZ4 v1.7.3	2017
Objetivo upstream	LZ4 v1.10.0	22 de julio de 2024

El proyecto upstream publicó la v1.10.0 el 22 de julio de 2024 y la llamó "Multicores edition". Sus notas de versión dicen que incorpora más de 600 commits. Su función principal es la compresión multihilo. También declara estable la compresión con diccionario.

El problema de las comprobaciones de límites

El argumento más sólido de la carta de presentación trata sobre la seguridad, no sobre la velocidad. La función LZ4_decompress_fast() bifurcada del kernel nunca comprueba si está escribiendo dentro de su búfer. "El LZ4_decompress_fast() bifurcado no tiene comprobaciones de límites, así que una entrada corrupta se sale del búfer de salida en ambas direcciones", escribió Wilczynski.

Una comprobación de límites es una prueba que impide que el código lea o escriba más allá del final de un bloque de memoria. Sin ella, unos datos comprimidos dañados u hostiles pueden hacer que el descompresor sobrescriba memoria ajena. Es el camino clásico hacia un fallo o un agujero de seguridad. La resincronización sustituye el código bifurcado por la versión de upstream.

El equilibrio entre velocidad y tamaño

La carta de presentación informa de una descompresión más rápida en todos los tamaños de bloque probados, de 4K a 256K. Las mejoras para la propia biblioteca LZ4 fueron:

• Bloques de 4K: un 11% más rápido
• Bloques de 16K: un 21% más rápido, la mayor mejora
• Bloques de 64K: un 17% más rápido
• Bloques de 256K: un 10% más rápido

Las pruebas a través de EROFS, un sistema de archivos de solo lectura, mostraron un 11% con 4K y un 14% con 64K.

El coste es el tamaño. En x86_64, el código compilado crece de 45K a 89K. La carta de presentación atribuye la mayor parte de ese aumento al analizador más completo de upstream.

La serie también cambia la forma de mantener el código. El kernel llevaría los archivos de upstream tal cual, en lugar de un fork editado a mano. "Una resincronización se convierte en una copia de directorio", escribió Wilczynski.

Qué significa para los desarrolladores

Compruebe primero si usa LZ4 en el kernel. La carta de presentación nombra cuatro usuarios: zram, erofs, f2fs y lib/decompress_unlz4. zram es un dispositivo de swap comprimido que vive en la RAM. EROFS es un sistema de archivos de solo lectura, y F2FS es un sistema de archivos diseñado para almacenamiento flash.

Si usa zram con LZ4, este es el cambio que con más probabilidad le afectará. El swap hacia zram ocurre bajo presión de memoria, cuando cada ciclo de CPU cuenta. Una mejora de dos dígitos en la descompresión puede notarse ahí como un sistema más ágil. Ejecute cat /sys/block/zram0/comp_algorithm para ver qué algoritmo usa su dispositivo zram.

Si distribuye imágenes sobre EROFS, la mejora del 11-14% se aplica a la lectura de archivos. Probablemente importa más cuando se leen muchos bloques pequeños a la vez, como durante el arranque. Haga pruebas en su propio hardware antes de contar con ello. Las cifras de la carta de presentación proceden de su propio entorno de pruebas.

Si compila para dispositivos muy pequeños, tenga en cuenta el aumento de 44K en el tamaño del código. En un kernel embebido con un presupuesto de flash ajustado, vale la pena medirlo.

Considere la corrección de las comprobaciones de límites como la verdadera razón para querer este cambio. Cualquier ruta que descomprima datos del disco o de la red con el antiguo decodificador rápido confía por completo en su entrada. Hasta que la serie se integre, prefiera las funciones de descompresión con comprobaciones en su propio código del kernel.

Se trata de una serie de parches en revisión, no de código fusionado. Siga la lista linux-kernel para ver las respuestas de los mantenedores. Ellas decidirán cuándo llega a una versión.