Kernel compilation on a top-end Linux workstation now takes about 15 seconds, and the people who benchmark it for a living think 10 seconds is next. Phoronix founder Michael Larabel built a default x86_64 kernel in 15 seconds on a dual-socket AMD EPYC machine last week, down from just over 22 seconds on the same hardware before a set of pending build-system patches. “The coffee window is closing,” he wrote on 25 September 2026.
The patches come from Linux memory-management developer Lorenzo Stoakes, who used a large language model to find where the kernel’s build system was stuck working on one core at a time, then audited and rewrote much of the code it produced. His 22-patch series claims full allmodconfig builds up to 36% faster, incremental builds up to about 70% faster and “no-op” rebuilds up to about 90% faster. Linus Torvalds has said he would “love for this all to go in”.
By 27 September, half of the series was queued in the kernel build tree’s branch for the next release. Tom’s Hardware summarised the benchmark that day. We went back to the Phoronix review, the kernel mailing list and the kernel’s git trees to explain what was measured, what the patches change, how the AI help was handled under the kernel’s own rules, when faster kernel compilation could reach Linux 7.4, and what it means for teams that build kernels every day.
Table of contents
- What Phoronix Measured: A 15-Second Kernel Compilation
- Why Kernel Compilation Stalled on a Single Core
- Inside the 22 Patches Speeding Up Kernel Compilation
- Kernel Compilation Results on Three Very Different Machines
- How an LLM Helped Find the Kernel Compilation Bottlenecks
- When Faster Kernel Compilation Could Reach Linux 7.4
- Can Kernel Compilation Really Drop Below 10 Seconds?
- What Faster Kernel Compilation Means for Developers and CI
- Frequently Asked Questions About Kernel Compilation Times
- References
What Phoronix Measured: A 15-Second Kernel Compilation
Phoronix has timed kernel compilation for more than 22 years, and Larabel calls it one of his favourite benchmarks. The figure he watches most closely is a clean “defconfig” build for x86_64: the kernel’s default configuration, compiled into an empty build directory.
The test machine
The rig was about as fast as a single build box gets. According to Tom’s Hardware’s summary of the review, it paired two AMD EPYC 9575F processors (128 cores and 256 threads in total) with 24 modules of 64 GB DDR5-6400 memory, a Samsung PM1743 3.84 TB PCIe 5.0 NVMe drive and a stock Ubuntu 26.04 LTS install.
Each EPYC 9575F has 64 cores, a 5.0 GHz boost clock, a 4.5 GHz all-core boost and 256 MB of L3 cache. Larabel calls it his “current favorite CPU for code compilation workloads”, two years after launch. He did not put the source tree on a RAM disk, which makes his kernel compilation times easier for other people to compare against.
From 22 seconds to 15
Before the patches, a defconfig kernel compilation took just over 22 seconds on this machine. With the fourth revision (v4) of Stoakes’s series applied, it took 15 seconds, a cut of about 32%. That is the “nearly a third” in Tom’s Hardware’s headline.
The heavier allmodconfig kernel compilation, which switches on every driver and subsystem that can be built as a module, fell from 169 seconds to 134 seconds, about 21% faster. That leaves the biggest standard kernel compilation approaching the two-minute mark on a single machine.
The gap between the two builds matters: the 15-second figure is for a small default kernel, while allmodconfig still takes more than two minutes on the same hardware.
How far kernel compilation has come
Larabel remembers AMD’s EPYC Milan generation, launched in 2021, as the point where a kernel build “finally” broke 30 seconds. His dual 9575F setup has typically needed about 20 seconds in his benchmarks. All the while the kernel has kept growing, and its source tree is now close to 41 million lines.
So the speed-up has come from hardware and software moving together, not from the codebase getting smaller. The latest step is on the software side, and Larabel notes that it also helps “proportionally” for people who are not running leading-edge processors.
Why Kernel Compilation Stalled on a Single Core
Compiling the C files is the part of kernel compilation everyone pictures, and it already runs in parallel. Make hands thousands of independent source files to as many compiler processes as the machine has threads. The trouble sits before and after that stage.
The serial tail of every build
Stoakes’s cover letter puts it bluntly: “A typical kernel build consists of a frustratingly large amount of time spent stuck in single-threaded bottlenecks.” Once the objects are compiled, several steps have historically run on one core while the rest of the machine waits.
The main offenders were symbol-table generation (kallsyms, fed by a 30-pattern sed script called mksysmap), module post-processing (modpost), the objtool pass over the linked kernel, and gzip compressing the final kernel image. On a 256-thread machine, every second spent on one core is a second in which more than 99% of the hardware does nothing.
Amdahl’s law at work
This is Amdahl’s law in practice: the part of a job that cannot run in parallel sets a floor on how fast the whole job can go, however many cores you add. As core counts climb, the parallel compile shrinks and the serial tail becomes a bigger share of each kernel compilation.
It also explains why the same patches help small machines less. On an 8-core laptop, compiling dominates a long build and the serial steps are a thin slice. On a many-core workstation, those serial steps can be a large slice of a 30-second kernel compilation.
Rebuilds that did nothing, slowly
The other bottleneck is make itself when little has changed. Each compiled object has a .cmd file that lists its header dependencies, which “often consists of over a thousand dependencies”, according to one of the patches. Make reads those lists on one core before it can decide there is nothing to do.
That is why a “no-op” allmodconfig build, where nothing has changed at all, took 15.3 seconds on a 64-core Threadripper with gcc before the series. Developers pay that cost constantly: every time they re-run make out of habit, switch branches or touch a single file.
Inside the 22 Patches Speeding Up Kernel Compilation
The series touches kbuild (the kernel’s build system), kallsyms, modpost, objtool, mksysmap and the Rust build rules. Stoakes sums up the approach as “parallelising single-threaded tasks as much as possible and improving the efficiency of code used in the build process”. He says nothing “too controversial” was included, and that tooling should behave exactly as before.
Module descriptors as assembly
For every module, modpost used to write a small C file (a .mod.c) and compile it like any other kernel source, pulling in a few hundred headers each time. An x86-64 allmodconfig build produces 11,189 of them, each taking about 0.24 seconds of CPU time. Module finalisation cost about 6,300 CPU-seconds and left roughly 1.3 GiB of dependency files for later builds to re-read.
Patch 14 emits those descriptors as assembly instead, and Stoakes checked the resulting sections byte for byte against the old output for 8,135 modules. On allmodconfig with clang 22, “make modules” from scratch fell from 64.5 seconds (6,306 CPU-seconds) to 28.5 seconds (518 CPU-seconds).
Batching thousands of tiny jobs
The new assembly files build so quickly that make could not hand them out fast enough: about 22,000 jobs lasting a few milliseconds each. Patch 15 groups modules into batches of 128, a size chosen after testing batches from 1 to 512. That takes the same “make modules” run from 28.9 seconds to 15.9 seconds.
Symbols read straight from the kernel image
Patch 8 replaces the mksysmap sed script with C code that reads the ELF symbol table directly. The old route ran nm three times over a 250 MiB file, writing and re-reading half a million lines on each pass. Patch 10 adds depcheck, a small C tool that checks each dependency’s timestamp once. For the amdgpu graphics driver directory it cuts the time make spends reading dependency data from 380 ms to 10 ms.
Parallel objtool and parallel gzip
Objtool, which checks the compiled kernel’s machine code, now decodes instructions on up to 16 threads, because Stoakes found that more threads only added overhead. The final patch swaps gzip for pigz, a parallel drop-in replacement, whenever pigz is installed. Compressing a 36 MiB kernel image drops from 1.6 seconds to 0.09 seconds on the 128-thread Threadripper test machine.
Here is where each group of patches saves kernel compilation time, using the figures published in the individual commit messages:
| Area | Patches | What changes | Measured effect |
|---|---|---|---|
| kallsyms and mksysmap | 2, 3, 8 | Token index, binary output, symbols read from the ELF file instead of three nm passes | Patch 3: kallsyms assembly per pass 0.57s to 0.16s |
| Dependency checks | 9, 10 | Per-object state and a C tool (depcheck) instead of make parsing every .cmd file | amdgpu directory: 2.2s to 0.4s |
| Toolchain probes | 11, 12 | About 30 duplicate compiler and linker probes per make run replaced by one check | defconfig no-op, clang: 0.94s to 0.66s |
| modpost and modules | 13 to 15 | Module descriptors emitted as assembly, then finalised in batches of 128 | make modules: 64.5s to 28.5s, then 28.9s to 15.9s |
| objtool | 16 to 19 | Relocation index, right-sized hash, parallel decoding on up to 16 threads | vmlinux.o pass, clang allmodconfig: 6.5s to 4.4s |
| Rust | 20, 21 | Rust crates built alongside the C code instead of before it | defconfig with Rust, clean: 36.5s to 32.6s |
| Compression | 22 | pigz used for the kernel image when installed | 36 MiB image: 1.6s to 0.09s |
Kernel Compilation Results on Three Very Different Machines
Stoakes benchmarked three machines: an AMD Threadripper 9980X workstation (64 cores, 128 threads), a two-socket AMD EPYC 9754 server (256 cores, 512 threads) and a 2022 MacBook Pro with Apple’s M2 chip (8 cores, arm64). Every figure in his cover letter is the best of several runs.
Defconfig: the everyday kernel compilation
The default configuration is the kernel compilation most developers run many times a day. Full builds improve by 19% to 28% on the x86 machines, but the incremental and no-op columns matter more for everyday work:
| Machine and compiler | Full build | Incremental | No-op |
|---|---|---|---|
| Threadripper, gcc | 32.5s to 26.3s (-19%) | 11.2s to 6.0s (-47%) | 1.1s to 0.60s (-45%) |
| Threadripper, clang | 34.5s to 27.2s (-21%) | 11.3s to 5.4s (-52%) | 1.3s to 0.66s (-49%) |
| EPYC, gcc | 28.7s to 20.6s (-28%) | 18.6s to 9.2s (-51%) | 1.7s to 0.66s (-61%) |
| EPYC, clang | 39.8s to 32.2s (-19%) | 19.6s to 8.6s (-56%) | 2.0s to 0.80s (-60%) |
| M2, gcc | 564.7s to 512.1s (-9%) | 18.0s to 9.9s (-45%) | 6.4s to 1.7s (-74%) |
| M2, clang | 615.1s to 564.1s (-8%) | 18.1s to 8.2s (-55%) | 7.1s to 1.7s (-76%) |
One detail stands out. The EPYC 9754 server has twice the threads of Larabel’s machine, yet it needed 20.6 seconds for a gcc defconfig build with the patches, against Larabel’s 15. The setups differ, but the 9754 is a dense, lower-clocked “Bergamo” part, which fits Larabel’s view that the highest core counts are not always the best choice for kernel compilation.
Allmodconfig: the heavy build
Allmodconfig is the kernel compilation stress test, because every option that can be a module is built as one. Here the relative gains are biggest on the machine with the most threads:
| Machine and compiler | Full build | Incremental | No-op |
|---|---|---|---|
| Threadripper, gcc | 344.2s to 278.6s (-19%) | 40.1s to 15.4s (-62%) | 15.3s to 1.4s (-91%) |
| Threadripper, clang | 342.6s to 266.8s (-22%) | 40.3s to 15.6s (-61%) | 16.2s to 1.8s (-89%) |
| EPYC, gcc | 188.0s to 121.1s (-36%) | 70.9s to 24.3s (-66%) | 30.6s to 1.5s (-95%) |
| EPYC, clang | 259.5s to 184.6s (-29%) | 70.4s to 24.3s (-65%) | 32.3s to 2.2s (-93%) |
The full-build cut ranges from 19% on the Threadripper with gcc to 36% on the EPYC server with gcc, which is where the “up to 36% faster” figure comes from.
Why the M2 MacBook barely moves
The MacBook’s full defconfig build improves by only 8% to 9%, from 564.7 to 512.1 seconds with gcc. With 8 cores, compiling is most of the kernel compilation and the serial tail is a small share of it, so there is less to recover. Its incremental builds still get 45% to 55% faster, and its no-op builds 74% to 76% faster.
The M2 figures also caught Linus Torvalds’s eye. After v3 he asked: “There’s something odd going on with that M2 gcc build. Why is it such an odd duck?” The v4 changelog records the outcome: “Fixed broken m2 numbers in cover letter as per Linus.”
A second opinion from the kbuild maintainer
Nathan Chancellor, one of the kbuild maintainers, ran the first version against his own large build matrices. On an 80-core Ampere Altra system, a full run fell from 6 hours 21 minutes 42 seconds to 5 hours 31 minutes 15 seconds, 13.22% faster. On a 32-core AMD system it fell from 3 hours 38 minutes 55 seconds to 3 hours 13 minutes 18 seconds, 11.7% faster.
He noted that the matrices differed between the machines, but said it was “good to see similar numbers across different environments.” That independent check matters, because a kernel compilation benchmark from the patch author is only the starting point for review.
How an LLM Helped Find the Kernel Compilation Bottlenecks
The Tom’s Hardware headline calls the patches “AI-assisted”, and the cover letter is unusually specific about what that meant. It has a section headed “LLM usage” that separates what the model did from what Stoakes did.
What Stoakes disclosed
“An LLM was used to first determine where the bottlenecks were then to figure out how to improve them,” he wrote. “It generated a lot of code, much of it hideous.” He says he “extensively audited and rewrote a lot of it”, edited the commit messages, cover letter and comments, and checked correctness by hand in both builds and running kernels.
The model also “orchestrated build runs, testing, debugging and analysis”, and Stoakes verified the performance gains manually. He does not name the model or the tool he used; his tags use the generic “LLM” form shown in the kernel’s own example.
The kernel’s rules for AI-assisted patches
The kernel’s documentation has a page on AI coding assistants. It says AI agents “MUST NOT add Signed-off-by tags”, because only a human can certify the Developer Certificate of Origin, and that the human submitter takes full responsibility for any AI-generated code. It asks for an Assisted-by tag to record the help.
Stoakes’s commits follow that pattern: each one carries “Assisted-by: LLM” above his own Signed-off-by line. It is the same balance Debian struck in August, when its developers voted not to ban AI-generated code and put the weight on human review and responsibility instead.
Human reviewers did the hard part
The review was heavy. The lore.kernel.org archives hold 105, 89 and 76 messages for the first three versions, counting the patches themselves, with input from Kees Cook, objtool maintainer Josh Poimboeuf, Rust lead Miguel Ojeda and the kbuild maintainers. Torvalds admitted the AI angle had worried him:
“This made me scared to look at the patches originally, and I held off in fear that the patches would be horrible and this build time improvement would be hugely controversial garbage code.”
His verdict after reading them was different: “None of the patches look at all horrible to me. You clearly excised the hideous parts.” He added that he was “all for merging this” through the proper maintainer trees, and explained why: “Build times are a pet peeve of mine.”
AI on both sides of the review
There was automated review too. Sashiko, a review bot that posts from a kernel.org address, commented on several versions. Stoakes’s changelogs describe checking “all of the hallucinated sashiko reports” and fixing the parts that were real, such as a missing error check, while noting that the thread sanitizer found races the bot missed.
So one AI system proposed the changes, another critiqued them, and people decided which critiques were right. That is the useful lesson for any team using AI coding tools: a model can search a large codebase for slow paths quickly, but a person has to own what ships. It is the same reason we urge caution after incidents like the Claude Code session that deleted 48,000 files.
When Faster Kernel Compilation Could Reach Linux 7.4
Phoronix expects the work to land in Linux 7.4, and the kernel’s git trees support that for about half of it.
What is already queued
On 25 September, 11 of the 22 v4 patches were committed to a kbuild branch called kbuild-next-speedups. On 27 September that branch was merged into kbuild-for-next, which feeds the linux-next integration tree ahead of the next merge window. The queued patches are numbers 1 to 8, 11, 12 and 22: the .modinfo, kallsyms, mksysmap and symbol-sorting changes, the toolchain probes and pigz compression.
A one-line follow-up fix from Sasha Levin, which keeps .modinfo when vmlinux is linked with –gc-sections, was added the same day. Two small fixes from the first version had already gone upstream separately.
What still needs sign-off
The rest of the series had not been queued by 27 September. That covers the object-state and depcheck patches (9 and 10), the modpost and module-batching work (13 to 15), the objtool changes (16 to 19) and the Rust build changes (20 and 21). Those include the biggest single win in the series, the move to assembly module descriptors.
Torvalds said early on that the objtool change “is fairly substantial and needs objtool people to approve”. Chancellor warned he might not reach the later patches “until after Plumbers”, the Linux Plumbers Conference. A patch enabling rustc’s parallel front end was dropped in v3; users who want it can set KRUSTFLAGS=-Zthreads=8, as Stoakes did in his own tests.
The published totals also assume three other patch series that are still in progress, including work from Josh Poimboeuf and Kees Cook. Stoakes says those dependencies “will all be in place when the series is merged”.
The release calendar
Linux 7.3 reached its fifth release candidate on 27 September. A mainline release usually follows rc7 or rc8, which points to Linux 7.3 in the second half of October and a two-week 7.4 merge window straight after. On the usual cadence, 7.4 itself would follow roughly nine weeks later, around the end of the year. Patches that miss the window would wait for 7.5.
| Version | Posted | Patches | Thread messages | What happened |
|---|---|---|---|---|
| v1 | 8 Sep 2026 | 23 | 105 | Torvalds: “I’d love for this all to go in” |
| v2 | 14 Sep 2026 | 21 | 89 | Two fixes taken upstream; rustc threading made opt-in |
| v3 | 17 Sep 2026 | 20 | 76 | rustc threading patch dropped; Torvalds queries the M2 figures |
| v4 | 23 Sep 2026 | 22 | Ongoing | 11 patches in kbuild-for-next by 27 Sep |
Can Kernel Compilation Really Drop Below 10 Seconds?
Nobody has published a 10-second defconfig kernel compilation yet. It is a prediction, and Larabel is open about that: “with next-gen processors I am betting on 10 seconds.”
The bet on Zen 6 “Venice”
His candidate is the AMD EPYC 9686F, a high-frequency part from the Zen 6 “Venice” generation with 96 cores and 192 threads, up to a 5.0 GHz boost and 384 MB of L3 cache. Paired with MRDIMM-12800 memory, and PCIe Gen6 storage according to Tom’s Hardware, it is the chip Larabel says he is “already drooling for”.
Compared with the 9575F, that is 50% more cores and 50% more L3 cache per socket at the same peak boost clock. On paper, that is the kind of jump that could take another third off a 15-second build.
The arithmetic of the last five seconds
Going from 22 seconds to 15 took a 32% cut. Getting from 15 to 10 needs a further 33%, and this time most of it has to come from hardware, because the easiest software wins have now been taken.
What stands in the way
Larabel’s own caveat is the one to watch: “At least until compilers achieve parallelizing compilation of individual source files, the very highest core counts aren’t necessarily the best for build servers.” GCC work on splitting a single file’s compilation across threads has been tried, “but years later nothing has crossed the finish line there.”
Stoakes also says the remaining software gains would be “very invasive (large scale C header changes)” or bring “diminishing returns”. And the 10-second target applies to defconfig only. Distribution kernels enable thousands of modules, so their kernel compilation times sit far closer to allmodconfig’s two-plus minutes on the same hardware.
What Faster Kernel Compilation Means for Developers and CI
For most readers the 10-second number is a curiosity. The incremental and no-op gains are the practical story, because that is where developers and build servers spend their kernel compilation time.
Tighter edit-compile loops
Take a developer on a Threadripper 9980X who rebuilds allmodconfig after small edits 100 times a day. Using the gcc incremental figures from the cover letter, that is 4,010 seconds (about 67 minutes) of waiting before the patches and 1,540 seconds (about 26 minutes) after, so roughly 41 minutes a day back. On defconfig, the same 100 rebuilds drop from about 19 minutes to 10.
Faster bisecting of regressions
Larabel singles out bisecting as a winner from faster kernel compilation. Git splits a range of commits in half at each step to find the change that broke something. A range of 1,024 commits takes 10 steps. If each step needs a full allmodconfig kernel compilation on the Threadripper with gcc, the patches take the total from 3,442 seconds (about 57 minutes) to 2,786 seconds (about 46 minutes).
CI pipelines and compute bills
Chancellor’s matrix results translate directly into machine time: the 80-core run saved 50 minutes 27 seconds and the 32-core run saved 25 minutes 37 seconds. For CI that bills by the minute, a kernel compilation that is 12% to 13% shorter means a 12% to 13% smaller bill for that job, with no change of hardware.
Speed matters most under pressure. When a cybersecurity fix lands in a stable kernel, teams that maintain custom kernels for appliances, embedded devices or cloud images must rebuild and test every configuration they ship, and faster rebuilds shorten that window. Our DevOps services team builds pipelines like these, and our software development team can help find the serial bottlenecks in your own builds.
What you can do today
- Build with every thread:
make -j$(nproc)is still the single biggest setting. - Install pigz now. Once patch 22 is merged, kbuild will use it automatically for the kernel image, and until then it costs nothing.
- Trim the configuration:
make localmodconfigcreates a config from the modules currently loaded, which shrinks a distribution-style build sharply. - Cache repeat work: ccache helps when the same files are rebuilt often, for example when switching branches.
- For kernels with Rust enabled,
KRUSTFLAGS=-Zthreads=8turns on rustc’s parallel front end, but its output is not yet reproducible, which is why the patch that would have enabled it was dropped.
Frequently Asked Questions About Kernel Compilation Times
How long does kernel compilation take on an ordinary PC?
It depends on the configuration and the number of cores. On Stoakes’s test machines, a gcc defconfig kernel compilation took 564.7 seconds (over nine minutes) on an 8-core M2 MacBook Pro and 32.5 seconds on a 64-core Threadripper before the patches. A distribution kernel with thousands of modules takes much longer than defconfig.
Did AI write the kernel patches?
A large language model located the bottlenecks, drafted fixes and ran tests, but Stoakes says he audited and rewrote much of the code and verified it by hand. Every commit carries an Assisted-by tag and his own Signed-off-by, as the kernel’s AI policy requires.
Has anyone achieved a 10-second kernel compilation?
Not yet. The best published figure is Phoronix’s 15 seconds for an x86_64 defconfig build on two EPYC 9575F processors. Ten seconds is Larabel’s prediction for next-generation Zen 6 EPYC hardware.
Do the patches change the kernel that gets built?
No. They change the build tooling, not the kernel code. Stoakes reports identical System.map output and byte-identical module sections. One caveat: pigz and gzip do not produce identical compressed files, so reproducible builds must use the same tool consistently.
Which Linux version will include faster kernel compilation?
The queued half is lined up for Linux 7.4. The remainder, including the module and objtool work, depends on reviews from the relevant maintainers and could land in 7.4 or a later release.
References
Approaching A 10 Second Linux Kernel Build (Phoronix)
Linux enthusiasts see 10-second kernel compilation times on the horizon (Tom’s Hardware)
[PATCH v4 00/22] kbuild: significantly speed up kernel builds (LKML)
Linus Torvalds on the kbuild speed-up series (LKML)
Nathan Chancellor’s build matrix results (LKML)
kbuild-next-speedups branch (kernel.org git)
AI Coding Assistants (Linux kernel documentation)
Kbuild (Linux kernel documentation)
