Linux 7.4 hace hasta 100 veces más rápido el flush de workqueues inactivas

Linux 7.4 ha integrado un cambio en las workqueues que hace de 10 a 100 veces más rápido el flush de una workqueue inactiva en máquinas grandes, informó Phoronix el 22 de octubre de 2026. El arreglo del desarrollador del kernel Tejun Heo se dirige a servidores con muchos núcleos, como los sistemas Intel Xeon y AMD EPYC. En esas máquinas, una operación habitual del sistema de archivos perdía tiempo revisando cada CPU, incluso cuando no había nada esperando.

Qué es el flush de una workqueue

Una workqueue es la forma en que el kernel entrega pequeñas tareas a hilos de trabajo en segundo plano, en lugar de hacerlas de inmediato. Los controladores y los sistemas de archivos la usan constantemente. Hacer flush de una workqueue significa esperar a que termine cada tarea que ya está en la cola.

Cada workqueue se conecta con sus hilos de trabajo mediante pool workqueues, o pwq. Una pwq es el enlace entre una workqueue y un grupo de hilos de trabajo. En un servidor grande puede haber una pwq por cada CPU posible.

El problema viene de un commit anterior del kernel, «workqueue: Make unbound workqueues to use per-cpu pool_workqueues». Desde ese cambio, un flush «recorre una pwq por cada CPU posible, tomando uno a uno cada bloqueo de pool», según la carta de presentación de la serie de parches. Lo hace incluso cuando la workqueue está inactiva. Más núcleos significaban más trabajo perdido en cada flush.

Quién lo encontró y dónde dolía

Yao Kai, ingeniero de Huawei, informó del sobrecoste a principios de septiembre, según Phoronix. El punto débil era XFS, un sistema de archivos de Linux muy usado. XFS hace flush de una de sus workqueues, la workqueue CIL, en cada log force. Es el momento en que debe escribir su diario en el disco.

En una máquina de 128 CPU, ese flush tardaba hasta 64 microsegundos cada vez, según el informe. Un microsegundo es una millonésima de segundo, así que 64 parece poco. Pero un sistema de archivos ocupado fuerza su registro muy a menudo, y el coste se acumulaba.

El arreglo lleva la cuenta de qué pwq se usaron de verdad desde el último flush, en listas por nodo. Un nodo es un grupo de CPU con su propia memoria local. Ahora un flush solo visita esas pwq activas. La serie tiene dos parches, «workqueue: Maintain pwq->total_in_flight» y «workqueue: Make flush_workqueue() visit only pwqs active since the last flush».

Las cifras de las pruebas

La serie de parches informa de sus resultados en una máquina de 192 CPU con dos nodos. Las workqueues per-cpu ejecutan las tareas en una CPU elegida; las unbound dejan que el planificador elija cualquier CPU.

Prueba en un servidor de 192 CPU y 2 nodos	Antes	Después
Flush de una workqueue per-cpu inactiva	40.000 por segundo	4,2 millones por segundo
Flush de una workqueue unbound inactiva	450.000	4,3 millones
16 hilos que encolan y hacen flush, per-cpu	30.000 flush por segundo	110.000 flush por segundo
16 hilos que encolan y hacen flush, unbound	60.000 flush por segundo	180.000 flush por segundo

La contrapartida se dice con claridad. «Los flush densos con todas las pwq activas no cambian en las workqueues per-cpu y son un 15-20% más lentos en las unbound», escribió Heo en su mensaje de commit, citado por Phoronix. Encolar trabajo nuevo no se ve afectado.

El arreglo ya viaja más allá de la rama principal. El 9 de septiembre, Yao Kai publicó una adaptación de los dos parches en la lista de correo del kernel de openEuler. Está dirigida al kernel de openEuler basado en la versión 6.6.

Linux 7.4 también reúne otras mejoras de velocidad en esta ventana de fusión, como un parche que abre archivos un 39% más rápido en pruebas y Dynamic PAMT de Intel TDX, que ahorra RAM en los servidores.

Qué significa para los desarrolladores

La mayoría de la gente nunca llamará directamente a un flush de workqueue. Lo notará a través del sistema de archivos y los controladores de los servidores grandes.

• Vuelva a medir XFS en máquinas con muchos núcleos. Si usa XFS en servidores con 100 CPU o más, compare las cargas que escriben mucho en el registro con Linux 7.4 y con su kernel actual. Las cargas que sincronizan a menudo con el disco son las que hay que mirar.
• Compruebe el coste de los flush con carga. El código que hace flush de workqueues unbound mientras todas las pwq están ocupadas puede ser un 15-20% más lento. Los desarrolladores del kernel con rutas críticas así deberían medirlas antes y después.
• No espere mejoras en máquinas pequeñas. El ahorro viene de saltarse las pwq inactivas. Un portátil con pocos núcleos tenía poco que saltarse.
• Vigile el kernel de su distribución. openEuler ya está adaptando la serie a su kernel 6.6. Otras distribuciones empresariales podrían seguirle, así que revise sus registros de cambios si no puede pasar a 7.4.