Il 22 ottobre 2026 Phoronix ha riferito che una modifica alle workqueue è stata integrata in Linux Git per Linux 7.4. Il cambiamento riguarda il percorso del flush, cioè l’operazione che controlla le code di lavoro del kernel: invece di visitare una coda per ogni CPU possibile, il flush visita quelle usate dal flush precedente. Le misurazioni citate mostrano risultati diversi secondo il carico.
Il flush visita le workqueue usate dal flush precedente
Le workqueue del kernel rinviano l’esecuzione di attività in modo asincrono. La modifica firmata dallo sviluppatore Linux Tejun Heo riguarda il flush, non il percorso con cui il lavoro viene accodato. Non riguarda le code userspace: si parla di un meccanismo interno al kernel Linux.
Il caso XFS ha evidenziato il costo del percorso
Secondo quanto riportato da Phoronix, l’ingegnere di Huawei Yao Kai aveva segnalato fino a 64 microsecondi spesi a percorrere la workqueue CIL di XFS durante ogni flush, su una macchina con 128 CPU. La CIL viene svuotata a ogni «log force», un’operazione legata alla registrazione delle modifiche del filesystem.
I tassi di flush variano secondo il carico
I valori ripresi da Phoronix dal messaggio del commit di Heo riguardano una macchina a due nodi con 192 CPU. Nei casi inattivi, il tasso dei flush per-CPU è passato da 40.000 a 4.200.000 al secondo; quello delle workqueue unbound, da 450.000 a 4.300.000. Con 16 thread, ciascuno impegnato ad accodare un elemento di lavoro e a eseguire un flush, i tassi sono passati rispettivamente da 30.000 a 110.000 e da 60.000 a 180.000 al secondo.
| Carico | Workqueue | Prima (flush al secondo) | Dopo (flush al secondo) | Rapporto di throughput |
| Inattivo | per-CPU | 40.000 | 4.200.000 | 105× |
| Inattivo | unbound | 450.000 | 4.300.000 | circa 9,6× |
| 16 thread | per-CPU | 30.000 | 110.000 | circa 3,7× |
| 16 thread | unbound | 60.000 | 180.000 | 3× |
Il throughput indica quanti flush vengono completati in un secondo. I rapporti in tabella confrontano quel tasso nei singoli casi: non misurano una riduzione equivalente della latenza delle attività. Per esempio, il rapporto di 105× deriva dal passaggio da 40.000 a 4.200.000 flush al secondo nel caso per-CPU inattivo.
Con carico denso, il risultato cambia
Quando tutte le workqueue dei pool erano attive, il tasso dei flush per-CPU è rimasto invariato; quello delle workqueue unbound è risultato inferiore del 15–20%. La modifica al flush, quindi, non ha prodotto lo stesso risultato in ogni condizione di carico.
