Phoronix meldde op 22 oktober 2026 dat een wijziging aan workqueues was opgenomen in Linux Git voor de ontwikkeltak Linux 7.4. Daardoor bezoekt een flush volgens de beschrijving voortaan de queues die sinds de vorige flush zijn gebruikt, in plaats van een queue voor elke mogelijke CPU. De gemelde cijfers laten grote verschillen per werklast zien.
Wat verandert er bij een kernel-workqueue?
Een workqueue is een mechanisme waarmee de Linux-kernel werk uitstelt om het later asynchroon uit te voeren. Een flush controleert of het werk in de queue is afgehandeld. De wijziging beperkt de queues die zo’n flush doorloopt tot queues die sinds de vorige flush zijn gebruikt. Het pad waarmee werk in de queue wordt gezet, blijft volgens de beschrijving ongewijzigd.
Het gaat om workqueues in de kernel, niet om een API voor workqueues in userspace.
Waarom XFS en systemen met veel CPU’s ter sprake komen
De aanleiding was volgens Phoronix een melding van Huawei-engineer Yao Kai over de XFS CIL-workqueue. Kai rapporteerde dat het doorlopen van die queue op een systeem met 128 CPU’s tot 64 microseconden per flush kostte. De CIL-workqueue wordt bij iedere log force geflusht.
De door Phoronix aangehaalde prestatiecijfers komen uit het commitbericht van Linux-ontwikkelaar Tejun Heo. Ze betreffen een systeem met 192 CPU’s en twee nodes. De tabel toont de gemelde flushes per seconde en de verhouding tussen de waarden voor en na de wijziging.
| Werklast | Workqueuetype | Voor (flushes/s) | Na (flushes/s) | Throughputverhouding |
| Inactieve queue | per-CPU | 40.000 | 4,2 miljoen | 105× |
| Inactieve queue | unbound | 450.000 | 4,3 miljoen | circa 9,6× |
| 16 threads die elk werk in de queue zetten en flushen | per-CPU | 30.000 | 110.000 | circa 3,7× |
| 16 threads die elk werk in de queue zetten en flushen | unbound | 60.000 | 180.000 | 3× |
De verhoudingen zijn berekend uit de gemelde aantallen flushes per seconde. Ze beschrijven throughput, oftewel het aantal flushes dat per seconde wordt verwerkt. Ze tonen niet aan dat de end-to-end-latency, de totale tijd tot een taak is afgerond, met dezelfde factor daalt.
Dichte belasting levert een ander resultaat op
Bij dichte flushes, waarbij alle pool-workqueues actief waren, bleef de per-CPU-uitkomst volgens de aangehaalde cijfers gelijk. De unbound-uitkomst lag 15 tot 20 procent lager. De resultaten wijzen dus op uiteenlopende effecten per werklast, niet op een vaste versnelling van elke kernel-workqueue.
