Linux 7.4 cuts one boot step from 268 s to 50 ms

On October 22, Linus Torvalds merged into Linux 7.4 a change by Tejun Heo that makes flushing an idle workqueue 10 to 100 times faster on large machines. Three days later the memblock pull request followed, carrying a patch by Google engineer Tarun Sahu that cut one boot step after a kexecA mechanism that loads and starts a new kernel from the running one, without going through the machine's firmware. from about 268 seconds to about 50 milliseconds. Linux 7.4 is still in the merge window that opened after 7.3 shipped on October 18.¹ ² ³ ⁴ ⁷

In both cases the kernel walked an entire structure to find the little that mattered: every possible CPU on a flush, every memory region from index 0 in memblock. The measured gains come from extreme setups, a 192-CPU machine in one case and hundreds of thousands of memory regions in the other.

A flush stops visiting queues nobody used

A workqueue is where the kernel leaves work for later.⁸ Code calls flush_workqueue() to wait until the items already queued have finished. Since a scalability commit for unbound workqueues, every flush walked one structure per possible CPU (the pool_workqueue, or pwq) and cycled that pool's lock, up to three times per flush. Yao Kai reported that XFS's CIL workqueue, tied to the log and flushed on every log force, spent up to 64 microseconds per flush in that walk on a 128-CPU machine.²

Skipping idle queues without further care would have been unsafe. Advancing each pwq's work "color" is what keeps a concurrently queued item from receiving an already-retired color that the flusher never sees, which would let a later flush return before the item finishes. Heo replaced the full walk with a record of active pwqs: each workqueue gained, per NUMA node, a lock, a mirror of the work color and a list. A pwq stays on the list until a visit finds it empty.²

The commit's measurements used a 192-CPU, 2-node machine:²

Scenario	Before	After
Flushing an idle per-cpu workqueue	40k/s	4.2M/s
Flushing an idle unbound workqueue	450k/s	4.3M/s
16 threads queueing and flushing, per-cpu	30k/s	110k/s
16 threads queueing and flushing, unbound	60k/s	180k/s

The "10 to 100 times" range describes idle flushes: the arithmetic works out to about 105 times for per-cpu and about 9.6 times for unbound. In the 16-thread test the gain is 3 to 4 times. When every pwq is active, flushing is unchanged on per-cpu workqueues and 15% to 20% slower on unbound ones. The queueing path is unchanged.² The commit reports no end-to-end XFS throughput figure, only the cost of the flush.

Memblock starts its search in the right place

Memblock manages physical memory in the first moments of boot, before the page allocator exists, and keeps a sorted array of regions. The functions memblock_add_range() and memblock_isolate_range() scanned that array from index 0 on every insertion. With only a few regions the cost is negligible. With hundreds of thousands of separate regions it grows with the square of their number.⁴

The commit's case is KHOKexec HandOver: preserves memory regions, and the state stored in them, from the outgoing kernel to the incoming one across a kexec., which preserves memory and the state stored in it from one kernel to the next across a kexec.⁶ When it registered hundreds of thousands of foliosGroups of contiguous memory pages that the kernel's memory management treats as a single unit. that were not adjacent to one another, KHO took about 268 seconds to retrieve the memory of 393k pages. Sahu made both functions start at an index found by binary search, which cuts the candidate search from O(N) to O(log N), and the same step dropped to about 50 ms. The commit also rebuilds memblock_search(), which had its own binary search, on top of the new helper.⁴

A second measurement, at a smaller scale, appears in the review thread. Dongli Zhang posted the boot log of a 32-CPU machine with THP disabled, which uses 4 KB pages. Before the patch, the gap between the memory-initialization line at 0.23 s and the SLUB line at 38.6 s showed a pause of about 38 seconds. With the patch, SLUB appears at 0.51 s.⁵ Zhang tested the first version of the patch, and the log is a list participant's report, not a controlled benchmark.

Dev Jain asked on the list whether binary search would hurt the common case. Sahu answered that on lists under about a hundred elements linear search makes good use of the cache, but that the code runs at boot and a difference of nanoseconds does not matter.⁵ Pratyush Yadav reviewed the patch, and it went in through the tree of Mike Rapoport, the memblock maintainer.³ ⁴

Who feels the difference

The faster flush shows up on servers with many CPUs and on workqueues that are flushed often, such as the XFS log. On a laptop with a few cores there are fewer CPUs to walk, so the gain is likely smaller. Binary search in memblock matters to anyone using KHO and kexec with a lot of fragmented memory, and the 268 s figure comes from the heavy-fragmentation scenario the author described.

Neither change reaches stable distributions until 7.4 ships and they adopt it. Until then, the code can still change across the release candidates.

Sources

1. The 7.3 kernel has been released · LWN.net · https://lwn.net/Articles/1101143/ · Oct. 18, 2026
2. workqueue: Make flush_workqueue() visit only pwqs active since the last flush · Tejun Heo · git.kernel.org · https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f1639cde5f5c1bee25498ef988227ee8cf5ddb04 · Sept. 1, 2026

Show 6 more sourcesHide sources

3. Merge tag 'memblock-v7.4-rc1' · Linus Torvalds · git.kernel.org · https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=394023fbe34fccec5d4db2576169d21e14c8d3d4 · Oct. 25, 2026
4. memblock: use binary search to locate candidate regions · Tarun Sahu · git.kernel.org · https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7933ad3f669670ca5f5f13de2b5cb0f92b91abf5 · Oct. 8, 2026
5. Re: [PATCH] memblock: use binary search to locate candidate regions · Dongli Zhang (Sept. 3, 2026) and Tarun Sahu (Sept. 4, 2026) · kexec mailing list · http://www.mail-archive.com/[email protected]/msg41726.html · http://www.mail-archive.com/[email protected]/msg41745.html
6. Kexec Handover Subsystem · Linux kernel documentation · https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/core-api/kho/index.rst · accessed Oct. 26, 2026
7. Merge tag 'wq-for-7.4' · Linus Torvalds · git.kernel.org · https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=031cb4ccf803f15b73e153d71024d75031bef5f3 · Oct. 22, 2026
8. Workqueue · Linux kernel documentation · https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/core-api/workqueue.rst · accessed Oct. 26, 2026