Phoronix zufolge wurde eine von Tejun Heo entwickelte Änderung an Kernel-Workqueues am 22. Oktober 2026 in den Git-Zweig für die Entwicklungsreihe Linux 7.4 übernommen. Sie soll Flushes gezielter machen: Statt für jede mögliche CPU eine Queue zu prüfen, besucht ein Flush die Queues, die seit dem vorherigen Flush verwendet wurden.
Was sich beim Flush einer Kernel-Workqueue ändert
Workqueues sind Warteschlangen, über die der Linux-Kernel Arbeit asynchron ausführen lässt. Die Änderung betrifft den Flush, also das Abarbeiten beziehungsweise Warten auf ausstehende Arbeit: Der Flush soll nur die seit dem letzten Flush genutzten Queues durchlaufen. Der Weg, auf dem Arbeit in die Queues eingereiht wird, bleibt laut dem Bericht unverändert. Die Meldung betrifft Kernel-Workqueues, keine Work-Queue-API für Anwendungen im Userspace.
Warum XFS und große Systeme eine Rolle spielen
Phoronix führt die Änderung auf einen Hinweis des Huawei-Ingenieurs Yao Kai zum XFS-CIL-Workqueue zurück. Kai zufolge konnte der Durchlauf dieser Queue auf einem System mit 128 CPUs pro Flush bis zu 64 Mikrosekunden beanspruchen. Die XFS-CIL-Workqueue wird bei jedem Log-Force geleert. Der berichtete Aufwand betrifft diesen konkreten Fall; er beschreibt nicht automatisch das Verhalten anderer Kernel-Aufgaben.
Was die berichteten Durchsatzwerte zeigen
Die von Phoronix aus Heos Commit-Nachricht wiedergegebenen Benchmarks liefen auf einem Rechner mit 192 CPUs und zwei Knoten. Die Tabelle zeigt Flushes pro Sekunde vor und nach der Änderung. Die Faktoren sind aus diesen Raten berechnet und beschreiben den Durchsatz, nicht die End-to-End-Latenz einer Aufgabe.
| Lastfall | Workqueue-Typ | Vorher (Flushes/s) | Nachher (Flushes/s) | Durchsatzfaktor |
| Leerlauf | per-CPU | 40.000 | 4.200.000 | 105× |
| Leerlauf | unbound | 450.000 | 4.300.000 | rund 9,6× |
| 16 Threads, die jeweils Arbeit einreihen und flushen | per-CPU | 30.000 | 110.000 | rund 3,7× |
| 16 Threads, die jeweils Arbeit einreihen und flushen | unbound | 60.000 | 180.000 | 3× |
Der größte Faktor gilt für den Leerlauf-Fall mit per-CPU-Workqueues. Bei unbound-Workqueues im Leerlauf liegt er bei rund 9,6. Unter der Last mit 16 Threads steigt der Durchsatz je nach Workqueue-Typ um etwa das 3,7-Fache beziehungsweise auf das Dreifache. Das sind Ergebnisse für die genannten Benchmarkfälle, keine Leistungszusage für beliebige Linux-Workloads.
Bei dichter Last fällt das Ergebnis anders aus
Wenn im dichten Test alle Pool-Workqueues aktiv waren, blieb der Durchsatz bei per-CPU-Workqueues unverändert. Bei unbound-Workqueues war er laut den wiedergegebenen Ergebnissen 15 bis 20 Prozent niedriger. Zusammen mit dem unveränderten Queueing-Pfad zeigt das: Die gemeldeten Verbesserungen betreffen vor allem bestimmte Flush-Fälle, während die dichte unbound-Last einen Rückgang aufwies.
