News › performance
By The Linux Camp News, October 23, 2026
Reported merged for Linux 7.4, the change avoids CPU-count-dependent scanning during workqueue flushes. The largest measured gains concern idle queues on large machines, not overall XFS performance.
Tejun Heo’s workqueue-flush optimization was reported merged into Linux Git for Linux 7.4 by Phoronix on October 22, 2026. Heo submitted the pull request on October 19. The change replaces a scan covering every possible CPU with visits only to queues used since the previous flush. This is a reported development-tree merge, not confirmation that a released distribution kernel contains it. 1 3
Workqueues let the kernel defer work for asynchronous execution; a flush waits for previously queued work to complete. The costly part here was preparing that flush. Yao Kai’s report explains that preparation walked per-CPU pool_workqueue entries, abbreviated pwqs, even for queues with little concurrent work. Earlier changes reduced locking costs but left the traversal proportional to CPU count. Visiting only entries active since the preceding flush avoids inspecting the unused entries. 1 2 3
XFS supplies a concrete reason to care. Its CIL log-push pipeline permits at most four push jobs scheduled or running concurrently, yet synchronous log forcing flushes the workqueue before submitting another push. That creates a mismatch on large systems: little concurrent work, but potentially many queue entries to inspect. The optimization addresses that infrastructure overhead rather than removing the XFS flush and its role in completing earlier pushes. 2 3
Heo’s pull request describes idle flushes on large machines as 10 to 100 times faster. Phoronix quotes his commit message with results from a 192-CPU, two-node machine: idle per-CPU workqueue flush throughput increased from 40,000 to 4.2 million per second, and idle unbound throughput from 450,000 to 4.3 million. These are attributed workqueue benchmarks, not independent Phoronix testing or measurements of whole-filesystem speed. 3 1
For evaluation, separate idle or sparsely active queues from densely active ones rather than applying the headline multiplier to a server workload. The quoted 16-thread queue-and-flush test improved from 30,000 to 110,000 flushes per second for per-CPU workqueues and from 60,000 to 180,000 for unbound workqueues. With every pwq active, however, per-CPU performance was unchanged and unbound flushes were 15–20% slower. The enqueue path itself is unchanged. 1
The evidence does not establish the final optimization’s end-to-end fsync benefit. Heo’s September patch announcement explicitly asked for testing against the reported fsync latency issue; the supplied merge report instead gives workqueue-level results. Filesystem throughput and tail-latency measurements therefore remain necessary before translating the flush improvement into an application-performance claim. 4 1