On Mon, Sep 14, 2026 at 10:24 AM Lorenzo Stoakes (ARM) <[email protected]> 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.
This confused the LWN article... :) There is a critical path in the graph, indeed, and doing it in `prepare` is painful, but to clarify: each crate is already built in parallel with others where possible, and the fact that each crate is built by one `rustc` is unrelated, plus the flag this patch proposes is also unrelated to that. I guess the LLM was trying to add context to the numbers below, but it looks like it will easily confuse readers. > Each time a change is made to any of the bindings, it triggers a rebuild. This seems oddly focused (i.e. not sure why `bindings` is mentioned in particular). It is also at least independent of this patch, i.e. it will remain true regardless of the patch. > rustc has a parallel front end, enabled with -Zthreads, available since > rust 1.84 [0] and therefore on every rustc the kernel supports. > > It is not yet stable and its output is not reproducible, so it cannot be > used by default - stabilisation is being worked on [1]. Not sure what it means by "by default". In any case, the main issue with the flag is that it has had issues recently, not so much the fact that it is unstable. > Add optional build parameter KBUILD_RUST_THREADS, which when set passes > that many threads to rustc. > > Observed build time changes with KBUILD_RUST_THREADS=8 (rustc 1.98, clang): I assume the improvements are most notable due to the work being on `prepare`, i.e. there is no other work available. When that is relaxed, this should be way less needed. Though it will be still very nice to have for full Rust rebuilds, like when changing the compiler versions often, due to `core` mainly (e.g. I have to do that often, so I would like it :). In any case, I am not sure about adding a Kbuild variable already for this at the moment, especially with that name, i.e. it is not really "threads" but "frontend jobs" and the flag will not be called that in the future anyway. And if someone wants to risk their kernel builds, then they can already pass the flag today... (We probably also want to know what the flag will finally do before committing to particular names, e.g. whether it affects codegen/reproducibility in any way. But perhaps Kbuild doesn't mind having new variables that may be replaced soon.) Thanks! Cheers, Miguel
