Parches para Linux podrían acelerar Zstd al eliminar una detección redundante

Tres parches enviados al desarrollo del kernel de Linux buscan corregir una detección redundante de BMI2 que, según pruebas atribuidas a Usama Arif, redujo 71% el tiempo de descompresión Zstd en un punto de referencia criptográfico.

***

• La implementación actual comprueba el soporte de BMI2 cada vez que crea un contexto de compresión o descompresión.
• Las instrucciones CPUID utilizadas para esa detección pueden ejecutarse repetidamente en rutas de trabajo como SquashFS.
• Las pruebas citadas en la propuesta registraron una mejora de 71% en descompresión y 18% en compresión.

El kernel de Linux podría obtener una aceleración considerable en sus tareas de compresión y descompresión Zstd mediante tres parches que corrigen una detección repetitiva del conjunto de instrucciones BMI2.

La propuesta, enviada el 26 de agosto de 2026 a la lista de correo del kernel, parte de un hallazgo atribuido al desarrollador Usama Arif sobre el modo en que el código decide qué ruta de ejecución utilizar. En una prueba de referencia vinculada con criptografía, la modificación redujo 71% el tiempo de descompresión y 18% el de compresión.

Zstd es una tecnología de compresión empleada dentro de varios componentes de Linux para reducir el espacio ocupado por datos y acelerar su procesamiento. El código del kernel puede utilizar una ruta genérica o una ruta optimizada para BMI2, un conjunto de instrucciones de manipulación de bits disponible en determinados procesadores modernos. La disponibilidad exacta depende del hardware y del entorno de ejecución.

Una comprobación repetida en una ruta activa

La detección dinámica no constituye por sí misma un problema, porque permite que el kernel conserve compatibilidad con procesadores antiguos y elija la implementación adecuada al iniciar una operación. El inconveniente señalado en la propuesta aparece después: el código vuelve a comprobar la capacidad del procesador cada vez que crea un nuevo contexto de compresión o descompresión. Si la capacidad ya fue identificada y el sistema continúa operativo, esa comprobación puede resultar redundante.

Para averiguar si el procesador admite BMI2, la implementación ejecuta dos instrucciones CPUID serializantes. Según la descripción de los parches, estas operaciones pueden tener un costo adicional en entornos virtualizados, aunque el impacto concreto dependerá del procesador, del hipervisor y de la carga de trabajo.

El impacto puede hacerse visible porque la comprobación aparece en rutas que se activan con frecuencia. SquashFS, por ejemplo, puede encontrarse con esa detección durante la descompresión de bloques, mientras que EROFS, Btrfs y F2FS pueden crear un contexto por operación. El código de criptografía basado en Zstd también puede inicializar un contexto cada vez que procesa una operación.

El resultado es que una tarea aparentemente pequeña puede repetirse al ritmo de cada bloque o solicitud. En lugar de pagar el costo de CPUID una sola vez y reutilizar la información, el sistema vuelve a preguntar si dispone de BMI2 antes de seleccionar la ruta optimizada, una decisión que la propuesta considera innecesaria.

El alcance de la propuesta

Los tres parches plantean detectar el soporte de BMI2 una sola vez y conservar el resultado para las operaciones posteriores. Con ese cambio, el kernel podría seguir utilizando la ruta genérica en equipos antiguos, pero evitaría repetir la consulta en máquinas que ya confirmaron la presencia de las instrucciones optimizadas.

La diferencia medida en la prueba atribuida a Arif fue particularmente amplia en la descompresión. El punto de referencia crypto_acomp registró una reducción de 71% en el tiempo necesario para descomprimir, mientras que la compresión experimentó una mejora de 18%, cifras que sugieren que el costo de detección puede acumularse cuando aparece repetidamente.

La magnitud de la mejora no significa que todas las cargas de trabajo obtendrán exactamente esos porcentajes. El resultado dependerá del sistema de archivos, del tamaño y tipo de los bloques, del procesador, del entorno de ejecución y de cuánto peso tenga la propia compresión dentro de la tarea completa. Además, las cifras corresponden a pruebas iniciales y no a una garantía general de rendimiento.

SquashFS podría ser uno de los casos más sensibles si su flujo de descompresión repite la detección por bloque. EROFS, Btrfs, F2FS y las funciones criptográficas que utilizan Zstd también podrían reducir trabajo innecesario cuando sus operaciones requieran crear contextos con frecuencia, aunque la validación final dependerá de las pruebas y revisiones realizadas por la comunidad.

Revisión antes de llegar al kernel

Los parches todavía se encuentran fuera del código definitivo y fueron enviados para revisión en la lista de correo del kernel de Linux. Ese proceso permite que otros desarrolladores examinen la lógica, reproduzcan los resultados y comprueben que la detección única no introduzca problemas de compatibilidad en arquitecturas o escenarios que no aparecieron en la prueba inicial.

La propuesta debe conservar la capacidad de ejecutar la implementación genérica cuando BMI2 no esté disponible, una condición necesaria para mantener el funcionamiento en procesadores más antiguos. También tendrá que demostrar que el resultado almacenado durante la inicialización permanece confiable durante toda la vida del sistema, que es precisamente la premisa utilizada para evitar nuevas llamadas a CPUID.

El caso ilustra una característica habitual de la optimización de sistemas: una operación muy costosa puede pasar inadvertida cuando aparece una sola vez, pero convertirse en un lastre importante al repetirse dentro de un ciclo de alto tráfico. En este escenario, la penalización no provendría de la compresión Zstd en sí, sino de preguntar reiteradamente qué capacidades posee una CPU que ya fue identificada.

Si la revisión concluye favorablemente y los cambios se incorporan, los beneficios podrían alcanzar a distintos sistemas de archivos y subsistemas sin exigir modificaciones en el hardware de los usuarios. Por ahora, el dato disponible es que los parches están en evaluación y que las mediciones iniciales de crypto_acomp apuntan a una mejora sustancial, especialmente en la descompresión.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín