Re: [PATCH 20/23] kbuild: rust: parallelise rustc front end

On Fri, Sep 11, 2026 at 09:00:40PM +0200, Nicolas Schier wrote:

On Tue, Sep 08, 2026 at 09:55:20PM +0100, Lorenzo Stoakes (ARM) wrote:

quoted

Rust crates are compiled in a serial chain on the critical path - core,
bindings, kernel crates and then the drivers - each a rustc invocation.

With CONFIG_RUST set and every rust driver enabled, the entire chain takes
around 25 seconds on a 128-thread machine, with the associated C code
taking 24 seconds.

Each time a change is made to any of the bindings, it triggers a rebuild.

Use the -Zthreads option to have rustc perform builds in parallel. This has
been available since rust 1.84 (rust-lang/rust#132282), and the kernel
requires rust 1.85 or above.

A future -j/--jobs option is planned for
rustc:(rust-lang/compiler-team#1005), so check to see if this available and
if so use it.

If the user's rustc supports neither, then it falls back gracefully and
neither are used.

The threads are taken from make's jobserver, so a parallel build is not
oversubscribed. It was found that benefits level off at 8 threads (16 was
found to be around the same, and 32 slower).

[...]

quoted

diff --git a/Makefile b/Makefile
index 997fc7ebe096..7d23d7b64be3 100644
--- a/Makefile
+++ b/Makefile

@@ -1204,6 +1204,10 @@ KBUILD_RUSTFLAGS += --remap-path-prefix=$(srcroot)/= --remap-path-scope=macro
 endif
 endif

+ifdef CONFIG_RUST
+KBUILD_RUSTFLAGS += $(if $(CONFIG_RUSTC_HAS_JOBS),-j8,$(if $(CONFIG_RUSTC_HAS_ZTHREADS),-Zthreads=8))
+endif

Is there a reason for the 'ifdef CONFIG_RUST'?

Hard-coding '8' feels a bit odd.  If some kind of KBUILD_RUST_JOBS would
be used, it could allow users to disable or override the parallelism for
rust.  Does it make sense to have rust parallelism configurable?

Have decided to go with a build var for v2 - KBUILD_RUST_THREADS=n - which
solves the default thread count, the instability issues and the confiigurability
all at once! :)

--
Nicolas

--
Cheers, Lorenzo