Zstd en Linux 7.4 evitará una inicialización redundante que lastra el rendimiento
Dos parches de Usama Arif difieren la inicialización de los streams de compresión y descompresión hasta la primera iteración, con subidas de hasta el 35% al descomprimir dentro de una máquina virtual.
Usama Arif ha publicado una serie de dos parches que eliminan una inicialización redundante en el código Zstd del kernel de Linux. El problema era sencillo de describir: al arrancar los streams de compresión y descompresión se hacía una inicialización de más, cuyo resultado se descartaba sin haber procesado un solo byte. Con el cambio, la inicialización de cstream y dstream se pospone hasta la primera iteración del recorrido.
Los dos parches ya están en la rama cryptodev del repositorio del kernel, dentro del subsistema de criptografía, y deberían entrar en la próxima ventana de fusión de Linux 7.4. No es un rediseño de Zstd ni un cambio de formato: es quitar trabajo que nadie aprovechaba.
Qué gana quien lo despliegue
La carta de presentación de la serie incluye medidas sobre un benchmark de crypto_acomp con bloques de 4KB. La compresión mejora un dígito porcentual, mientras que la descompresión sube un 13% en metal desnudo y un 35% cuando la prueba corre dentro de una máquina virtual. Esa diferencia entre los dos entornos es la parte interesante: el coste de una inicialización desperdiciada se nota mucho más cuando hay virtualización de por medio, que es exactamente el escenario de buena parte de la infraestructura actual.
El autor no es nuevo en esta zona del kernel. Estos parches llegan después de otra serie suya centrada en corregir una ineficiencia mayor en el mismo código de compresión Zstd, lo que da una idea de cuánto margen quedaba ahí dentro. El propio texto de presentación reconoce que la inicialización duplicada pasaba desapercibida porque no rompía nada: simplemente se pagaba dos veces por un paso que solo hacía falta una vez.
Por qué importa
Zstd está por todas partes en un sistema Linux moderno: se usa en el arranque, en sistemas de ficheros comprimidos, en el intercambio de páginas y en buena parte del empaquetado de software. Un porcentaje de un dígito en compresión no suena a gran cosa, pero en descompresión el 35% en VM es otra historia, porque descomprimir es la operación que ocurre en el camino caliente de casi todo lo que lee datos comprimidos. Y el escenario virtualizado es el pan de cada día en nube y en contenedores.
Queda por ver el número final que reporte el merge window y si las cifras se sostienen sobre cargas reales y no solo sobre el microbenchmark de crypto_acomp, que es donde se midieron. El parche es pequeño y el beneficio no depende de hardware concreto, así que lo raro sería que se quedara fuera. Para quien mantiene flotas con Zstd de por medio, es de esos cambios que no hay que activar ni configurar: llegan solos con la versión.
