Phoronix informó el 22 de octubre de 2026 de que el cambio de Tejun Heo para las workqueues se había integrado en el repositorio Git de Linux para la rama de desarrollo Linux 7.4. La modificación cambia qué colas visita cada vaciado o flush: recorre las workqueues usadas desde el vaciado anterior, en vez de revisar una por cada CPU posible.

Qué cambia en el vaciado de las workqueues

Las workqueues son colas del kernel que aplazan trabajo de forma asíncrona. El cambio afecta al recorrido que realiza el flush, mientras que la ruta que encola el trabajo permanece igual, según las cifras del mensaje del commit de Heo reproducidas por Phoronix.

La mejora se refiere a las workqueues del kernel Linux, no a una API de colas de espacio de usuario.

El caso de XFS que motivó el cambio

Según informó Phoronix, Yao Kai, ingeniero de Huawei, comunicó que recorrer la workqueue CIL de XFS podía consumir hasta 64 microsegundos por flush en una máquina de 128 CPU. XFS vacía esa cola cada vez que fuerza el registro, una operación denominada log force. Phoronix situó el informe de Kai a principios de septiembre de 2026.

Las tasas de flush varían según la carga

Phoronix reprodujo cifras atribuidas al mensaje del commit de Heo para un sistema de 192 CPU y dos nodos. En las pruebas con 16 hilos, cada hilo encolaba un elemento de trabajo y ejecutaba un flush.

CargaTipo de workqueueAntes (flushes/s)Después (flushes/s)Relación entre tasas
Inactivaper-CPU40.0004.200.000105×
Inactivaunbound450.0004.300.000≈ 9,6×
16 hilosper-CPU30.000110.000≈ 3,7×
16 hilosunbound60.000180.0003×

Las proporciones comparan flushes completados por segundo en cada caso. Miden rendimiento, no una reducción equivalente de la latencia de extremo a extremo.

La carga densa da un resultado distinto

Cuando todos los pool workqueues estaban activos, las tasas de los flushes densos per-CPU no cambiaron; las de los flushes unbound fueron entre un 15 % y un 20 % más lentas, según las cifras reproducidas por Phoronix.