Linux 7.4 Makes Workqueue Flushing 10-100x Faster on Big Servers

Kernel developers rarely allow themselves loud claims, but a change to the workqueue mechanism merged into the Linux 7.4 Git tree has earned one honestly: the authors speak of a "10 to 100 times faster" improvement.

Workqueues are used to defer work asynchronously inside the kernel. The problem lay in the flush procedure: previously it visited one queue per possible CPU. On today's servers with dozens or hundreds of cores — Intel Xeon and AMD EPYC — that turned into noticeable overhead.

What changed

Flushing now visits only the queues used since the last flush, rather than one per CPU. On large machines, idle flushes become 10 to 100 times faster. According to the developers, XFS takes this path on every log force.

The work grew out of a September report from Huawei engineer Yao Kai, who noticed that the XFS CIL workqueue, flushed on every log force, spent up to 64 microseconds on the walk on a 128-CPU machine.

The numbers

The improvement's author — longtime kernel developer Tejun Heo — cites striking figures in his commit. On a 192-CPU two-node machine, flushing an idle per-cpu workqueue jumps from 40,000 to 4.2 million operations per second, and an unbound one from 450,000 to 4.3 million. With 16 threads each queueing a work item and flushing, the rate rises from 30,000 to 110,000 flushes per second on a per-cpu queue and from 60,000 to 180,000 on an unbound one.

There are trade-offs: dense flushes, when every queue is active, are unchanged on per-cpu workqueues and 15-20% slower on unbound ones. The queue path itself is unchanged.

Going from 40,000 to 4.2 million operations per second is a feat by any metric. And, as Phoronix wryly notes, in 2026 it is especially pleasing that it was written by a human and not by AI.

Source: Phoronix