Linux 7.4 makes workqueue flushes 10 to 100 times faster on big servers

October 18, 2026. Linux 7.3 ships, and the Linux 7.4 merge window opens immediately. October 22, 2026. The workqueue pull request lands, authored by longtime maintainer Tejun Heo. September 2026. A Huawei engineer, Yao Kai, had reported that a XFS CIL workqueue spent up to 64 microseconds walking unused queues on every flush on a 128-CPU machine. The fix fits in one sentence: stop visiting queues that have not been used since the last flush.

The waste nobody saw

A workqueue lets the kernel defer work asynchronously: a subsystem queues a task into a list, and a worker consumes it later. Since the concurrency-managed workqueue rework of the 2010s, the kernel distinguishes two families: per-cpu queues, where each CPU owns its own worker pool, and unbound queues, where workers are not pinned to a specific CPU. Both families are covered by the fix, with slightly different results.

The flaw fixed in Linux 7.4 is not in running the work — it is in the flush, the operation that guarantees queued work has finished before continuing. Until now, flushing a workqueue meant walking one queue per possible CPU, even when almost all of them were empty and idle. On a 128- or 192-core server, that empty walk becomes measurable — and it is exactly what XFS pays on every log force.

The XFS CIL (commit item list) groups modifications waiting to be written to the journal. Every log force — triggered by an fsync, a transaction or a rotation — flushed a workqueue, which then walked one queue per possible CPU. On a 128-CPU machine, Yao Kai’s report priced that walk at 64 microseconds per flush: pure wasted time, multiplied by the number of log forces in a sustained transactional workload.

Tejun Heo’s commit summarizes the fix: “Flushing a workqueue now visits only the queues used since the last flush instead of one per possible CPU. Idle flushes get 10 to 100 times faster on large machines, which XFS hits on every log force.” In other words, you only visit the queues that were actually used since the previous flush.

Numbers that do not lie

The commit’s measurements show the scale of the win. On a 192-CPU, two-node machine:

• an idle per-cpu workqueue flush goes from 40,000 to 4.2 million operations per second;
• an idle unbound workqueue flush goes from 450,000 to 4.3 million;
• with 16 threads each queueing an item and flushing, throughput rises from 30,000 to 110,000 flushes per second on per-cpu workqueues, and from 60,000 to 180,000 on unbound ones.

Dense flushes — where every queue is active — are unchanged on per-cpu workqueues and 15 to 20 percent slower on unbound ones. The queueing path is untouched. Phoronix’s Michael Larabel notes dryly that a jump from 40,000 to 4.2 million “is quite a feat — especially in 2026 and not being AI authored.”

# Whether you are affected: a high core count and a kernel older than 7.4.
uname -r     # prints the version — the optimization lands with 7.4
nproc        # beyond 64 cores, the empty walk starts to cost real time

A wave of optimizations in Linux 7.4

This fix is not isolated. Linux 7.4 concentrates several gains of the same kind, all configuration-free:

• the slab update, merged on October 23, improves a memory-management benchmark by 24 percent;
• the kbuild patches from Arm engineer Lorenzo Stoakes cut incremental kernel build time by up to 70 percent, removing single-threaded bottlenecks;
• the scheduler gains latency improvements for short-slice tasks and an SMT preference for the upcoming NVIDIA Vera;
• coredumps over Unix sockets gain sparse support, which can shrink them to 1 percent of their non-sparse size.

What links these changes is a single philosophy: 2026 performance comes less from hardware than from removing wasted work inside the kernel itself, often surfaced by reports from massive fleets like Yao Kai’s. A 128- or 192-CPU fleet exposes costs nobody noticed on a 16-core box.

For maintainers, the origin of the fix matters as much as the numbers. The optimization came from a September report by a Huawei engineer measuring real fleet overhead — not from a benchmark suite or an AI-generated patch. Tejun Heo, who has maintained the workqueue subsystem for years, turned a one-line observation into a change in complexity class.

The trade-off is explicit. Dense flushes, where every queue is active, are unchanged on per-cpu workqueues and 15 to 20 percent slower on unbound ones. The commit accepts that small regression on the saturated case to win big on the common, mostly-idle case. For the vast majority of workloads, workqueues spend most of their life empty; that is the case the new walk optimizes.

What it actually changes for your workloads

The win concentrates where nobody looks: idle flushes. A database that forces its journal thousands of times per second, or a hypervisor that syncs its virtual devices, spends most of its time in empty workqueues — exactly the case this optimization makes 10 to 100 times cheaper.

The mechanism is worth spelling out because it is simple and general. Instead of keeping a static index of “one queue per possible CPU,” the workqueue now remembers which queues were actually used since the last flush and walks only those. The cost of a flush becomes proportional to recent activity, not to the size of the machine. That is a change in complexity, not a micro-tuning.

Two nuances to keep in mind. First, the gain shows up on machines with a large number of possible CPUs, typically beyond 64 cores; below that, the saving is real but negligible. Second, the commit flags a 15 to 20 percent regression on dense unbound flushes, a case that continuously saturated workloads should watch.

Verdict

If you run servers above 64 cores — databases, XFS filesystems, hypervisors — plan the move to Linux 7.4 as soon as it goes stable. The win is free, needs no configuration, and targets precisely the workloads that suffer from XFS log force latency and workqueue flush overhead.

If your fleet is more modest, do not force a backport: the empty-walk cost only becomes significant at high core counts. Note three things regardless. First, the optimization also applies to virtual machines with many vCPUs, not just bare metal. Second, keep an eye on the 15 to 20 percent regression on dense unbound flushes: workloads that saturate their queues continuously deserve a benchmark before you flip them to production. Third, treat this as one more reason to track kernel cycles closely: the cheapest performance wins of 2026 are not bought — they are updated in.

References

• Phoronix — Linux 7.4 Workqueue Changes Bring A “10 To 100 Times Faster” Optimization
• LKML — Workqueue pull request (Tejun Heo)
• Initial report by Yao Kai (Huawei) on unbound workqueue overhead
• Phoronix — Linux 7.4 Merges Slab Updates With A Nice Performance Improvement
• Phoronix — Linux 7.4 Begins Landing Patches To Speed Up The Kernel Build Process