Linux 7.4 macht Flushes leerer Workqueues bis zu 100-mal schneller

Linux 7.4 hat eine Workqueue-Änderung übernommen, die das Flushen einer leeren Workqueue auf großen Maschinen 10- bis 100-mal schneller macht. Das berichtete Phoronix am 22. Oktober 2026. Der Fix des Kernel-Entwicklers Tejun Heo zielt auf Server mit vielen CPU-Kernen, etwa Systeme mit Intel Xeon und AMD EPYC. Auf diesen Maschinen verschwendete eine alltägliche Dateisystem-Operation Zeit, weil sie jede CPU prüfte, selbst wenn nichts wartete.

Was ein Workqueue-Flush ist

Eine Workqueue ist der Weg des Kernels, kleine Aufgaben an Hintergrund-Threads abzugeben, statt sie sofort zu erledigen. Treiber und Dateisysteme nutzen sie ständig. Eine Workqueue zu flushen heißt, zu warten, bis jede bereits eingereihte Aufgabe fertig ist.

Jede Workqueue ist über Pool-Workqueues, kurz pwqs, mit ihren Worker-Threads verbunden. Eine pwq ist die Verbindung zwischen einer Workqueue und einem Pool von Workern. Auf einem großen Server kann es eine pwq für jede mögliche CPU geben.

Das Problem geht auf einen früheren Kernel-Commit zurück, „workqueue: Make unbound workqueues to use per-cpu pool_workqueues“. Seit dieser Änderung „durchläuft ein Flush eine pwq pro möglicher CPU und nimmt nacheinander jede Pool-Sperre“, heißt es im Begleitschreiben der Patch-Serie. Das passiert sogar, wenn die Workqueue leer ist. Mehr Kerne bedeuteten mehr verschwendete Arbeit bei jedem Flush.

Wer es gefunden hat und wo es schmerzte

Yao Kai, ein Huawei-Ingenieur, meldete den Overhead Anfang September, schreibt Phoronix. Betroffen war XFS, ein weit verbreitetes Linux-Dateisystem. XFS flusht eine seiner Workqueues, die CIL-Workqueue, bei jedem Log-Force. Das ist der Moment, in dem es sein Journal auf die Festplatte schreiben muss.

Auf einer Maschine mit 128 CPUs dauerte dieser Flush laut dem Bericht jedes Mal bis zu 64 Mikrosekunden. Eine Mikrosekunde ist eine Millionstel Sekunde, also klingt 64 nach wenig. Doch ein ausgelastetes Dateisystem erzwingt sehr oft einen Log-Force, und die Kosten summierten sich.

Der Fix merkt sich in Listen pro Node, welche pwqs seit dem letzten Flush tatsächlich benutzt wurden. Ein Node ist eine Gruppe von CPUs mit eigenem lokalem Speicher. Ein Flush besucht jetzt nur diese aktiven pwqs. Die Serie hat zwei Patches, „workqueue: Maintain pwq->total_in_flight“ und „workqueue: Make flush_workqueue() visit only pwqs active since the last flush“.

Die Benchmark-Zahlen

Die Patch-Serie meldet ihre Ergebnisse von einer Maschine mit 192 CPUs und zwei Nodes. Per-CPU-Workqueues führen Aufgaben auf einer bestimmten CPU aus; ungebundene lassen den Scheduler eine beliebige CPU wählen.

Test auf einem Server mit 192 CPUs und 2 Nodes	Vorher	Nachher
Flush einer leeren Per-CPU-Workqueue	40.000 pro Sekunde	4,2 Millionen pro Sekunde
Flush einer leeren ungebundenen Workqueue	450.000	4,3 Millionen
16 Threads, die einreihen und flushen, per CPU	30.000 Flushes pro Sekunde	110.000 Flushes pro Sekunde
16 Threads, die einreihen und flushen, ungebunden	60.000 Flushes pro Sekunde	180.000 Flushes pro Sekunde

Der Kompromiss wird offen genannt. „Dichte Flushes, bei denen jede pwq aktiv ist, sind auf Per-CPU-Workqueues unverändert und auf ungebundenen 15-20% langsamer“, schrieb Heo in seiner Commit-Nachricht, wie Phoronix zitiert. Das Einreihen neuer Aufgaben ist nicht betroffen.

Der Fix verbreitet sich bereits über den Hauptzweig hinaus. Am 9. September veröffentlichte Yao Kai einen Backport der beiden Patches auf der Kernel-Mailingliste von openEuler. Er zielt auf openEulers Kernel auf Basis von 6.6.

Linux 7.4 sammelt in diesem Merge-Fenster auch andere Beschleunigungen, darunter einen Patch, der Dateien im Test 39% schneller öffnet, und Intel TDX Dynamic PAMT, das Server-RAM spart.

Was das für Entwickler bedeutet

Die meisten Menschen rufen nie direkt einen Workqueue-Flush auf. Sie merken die Änderung über das Dateisystem und die Treiber auf großen Servern.

• Messen Sie XFS auf Maschinen mit vielen Kernen neu. Wenn Sie XFS auf Servern mit 100 oder mehr CPUs betreiben, vergleichen Sie Log-lastige Workloads unter Linux 7.4 mit Ihrem aktuellen Kernel. Workloads, die oft auf die Festplatte synchronisieren, sind die richtige Stelle zum Hinsehen.
• Prüfen Sie die Kosten voller Flushes. Code, der ungebundene Workqueues flusht, während jede pwq beschäftigt ist, kann 15-20% langsamer sein. Kernel-Entwickler mit solchen kritischen Pfaden sollten vorher und nachher messen.
• Erwarten Sie auf kleinen Maschinen keine Gewinne. Die Ersparnis entsteht, weil leere pwqs übersprungen werden. Ein Laptop mit wenigen Kernen hatte wenig zu überspringen.
• Beobachten Sie den Kernel Ihrer Distribution. openEuler portiert die Serie bereits auf seinen 6.6-Kernel zurück. Andere Enterprise-Distributionen könnten folgen. Prüfen Sie deren Changelogs, wenn Sie nicht auf 7.4 wechseln können.