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

[Nicolas Schier]

On Tue, Sep 08, 2026 at 09:55:20PM +0100, Lorenzo Stoakes (ARM) wrote:
> 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).
[...]

> 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?

-- 
Nicolas