Phoronix reported that Linux developer Tejun Heo’s workqueue-flush optimization was merged into Linux Git for the Linux 7.4 development line on October 22, 2026. The change makes a flush visit queues used since the previous flush instead of checking one queue for every possible CPU.
What changes in a kernel workqueue flush
Linux kernel workqueues defer work asynchronously inside the kernel. The reported optimization changes how a flush traverses those queues; the queueing path remains unchanged. This is a kernel change, not a userspace work-queue API change.
Phoronix connected the work to a report from Huawei engineer Yao Kai about the XFS CIL workqueue. XFS flushes that queue on every log force, and Kai reportedly measured up to 64 microseconds spent walking it per flush on a 128-CPU machine.
What the reported throughput figures show
Phoronix reproduced benchmark figures from Heo’s commit message for a 192-CPU, two-node system. The rates count flushes per second, so they describe throughput. The 16-thread cases involved each thread queueing a work item and flushing it.
| Workload | Workqueue type | Before (flushes/s) | After (flushes/s) | Throughput multiple |
| Idle | per-CPU | 40,000 | 4,200,000 | 105× |
| Idle | unbound | 450,000 | 4,300,000 | ≈9.6× |
| 16 threads queueing and flushing | per-CPU | 30,000 | 110,000 | ≈3.7× |
| 16 threads queueing and flushing | unbound | 60,000 | 180,000 | 3× |
The multiples are calculated from each pair of reported rates. End-to-end latency measures how long a task takes to complete, a different metric from flush throughput.
Dense flushes had a different result
When every pool workqueue was active, the reported dense per-CPU flush rate was unchanged, while dense unbound flushes were 15% to 20% slower. The results therefore varied with the workload and queue type.
