On Tue, Sep 15, 2026 at 07:32:02AM +0100, Miguel Ojeda wrote: > 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... :)
Sorry :) > > 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. Ack. And the other rust changes help maximise the parallelisation that exists :) > > 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 :). Yup that stalling is the key issue. I mean KRUSTFLAGS=-Zthreads=8 gives you a way to achieve that, I'll stick that into my scripts locally for now too I think as I've found it to be completely stable at least on my machine (TM). But definitely a TODO to pin for you guys once this is stabilised - it makes a big difference so when a. stabilised and b. kernel required minimum version has the stabilised feature -> easy to switch on :) > > 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... I agree, best to drop this in general, done for v3 already. I've updated the cover letter to say that KRUSTFLAGS=-Zthreads=8 is what was done with the build. > > (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.) I don't think it's too egregious either way tbh, but in any case dropping this for now is the way to go. > > Thanks! > > Cheers, > Miguel -- Cheers, Lorenzo
