A veces, las mejoras más interesantes del kernel de Linux no son las que hacen ruido, sino esas pequeñas optimizaciones que, sin darnos cuenta, terminan acelerando tareas que usamos cada día. Y eso es justo lo que ha ocurrido en las últimas horas con una nueva serie de parches que buscan mejorar el rendimiento de procesos de un solo hilo en máquinas con un número enorme de núcleos. Hablamos de escritorios potentes, estaciones de trabajo y, cómo no, servidores capaces de manejar cargas realmente grandes.
La noticia la trae Michael Larabel, publicada el 28 de noviembre de 2025, y gira en torno al trabajo de Gabriel Krisman Bertazi, ingeniero de SUSE, que ha dado a conocer una serie de parches en fase de RFC (Request For Comments). ¿La idea? Acelerar las tareas de un solo hilo en sistemas modernos con CPUs de altísimo recuento de núcleos. Y sí, puede sonar como un detalle menor… pero para quienes dependen del rendimiento fino en Linux, no lo es en absoluto.
Para entender qué está pasando aquí, hay que mirar dentro del kernel, concretamente a la estructura rss_stat. Esta estructura almacena estadísticas clave sobre cuánta memoria está utilizando un proceso, datos fundamentales para que el sistema tome buenas decisiones. El problema surge en CPUs gigantescas, donde la forma moderna de manejar estos contadores —con variables por CPU (pcpu)— empieza a generar un coste no tan pequeño. Y ese coste se nota especialmente al crear o destruir tareas, justo donde el kernel debería ser ágil.
Gabriel lo explica con un ejemplo muy claro. Cuenta que Jan Kara detectó que la introducción de contadores por CPU para rss_stat provocó una regresión del 10% en el tiempo del sistema al ejecutar gitsource en su máquina. Nada despreciable. Y, de hecho, fue el propio Jan quien propuso una solución hace tiempo: tratar de forma especial las tareas de un solo hilo. Si un proceso no va a estar recibiendo actualizaciones remotas de rss_stat desde docenas o cientos de núcleos, ¿para qué pagar el coste completo de la infraestructura por CPU? No tiene sentido.
La solución es, básicamente, una optimización dual. Para la mayoría de actualizaciones —las locales— se usa un contador sencillo, muy ligero. Y para las pocas actualizaciones remotas que podrían darse, se mantiene un contador atómico que asegura la coherencia. Es una idea elegante, honesta y muy alineada con cómo se piensa el rendimiento en sistemas Linux de gran escala: si algo no hace falta, no lo uses.
¿Y qué tal funciona esto en la práctica? Pues con resultados bastante prometedores. No hablaremos de milagros, pero sí de mejoras que, sumadas, marcan la diferencia. En pruebas sintéticas —esas que exprimen el sistema en escenarios muy específicos— se ha visto una mejora de entre un 6% y un 15% en el tiempo de creación de tareas en sistemas de 256 núcleos. No está nada mal. Y en un benchmark más cercano al mundo real, como kernbench, el rendimiento sube alrededor de un 1,5%, que puede sonar poco… pero en entornos donde cada milisegundo importa, es más que bienvenido.
Para ilustrarlo, Gabriel comparte una cifra interesante: en un sistema de 256 cores, donde asignar memoria pcpu para rss_stat es especialmente costoso, este cambio ha reducido el tiempo de reloj de pared —ese tiempo real que vemos como usuarios— entre un 6 % y un 15 % en un microbenchmark basado en ejecutar /bin/true en un bucle. Y cuando algo tan básico mejora tanto, es señal de que la optimización va por el camino correcto.
En resumen: un pequeño ajuste dentro del kernel que puede ofrecer un empujón notable a los procesos de un solo hilo en máquinas gigantescas. Un cambio aparentemente sencillo que demuestra, otra vez, que el kernel de Linux sigue evolucionando pieza a pieza, sin prisa pero sin pausa, y siempre con un ojo puesto en el rendimiento real.
Si utilizas Linux en entornos de alto rendimiento o simplemente te gusta seguir cómo se afina el corazón del sistema operativo, esta es una de esas mejoras que vale la pena tener en el radar.
Fuetne: Phoronix
Añadir comentario
Comentarios