On Tue Sep 15, 2026 at 12:58 PM BST, Lorenzo Stoakes (ARM) wrote: > On Mon, Sep 14, 2026 at 11:37:54AM -0700, Kees Cook wrote: >> On Mon, Sep 14, 2026 at 10:22:19AM +0100, Lorenzo Stoakes (ARM) wrote: >> > +# Rust code elsewhere in the tree depends upon rust/. >> > +ifdef CONFIG_RUST >> > +$(KBUILD_RUST_DIRS): | rust >> > +endif >> > [...] >> > +export KBUILD_RUST_DIRS := drivers lib mm samples >> >> Doesn't this make all of drivers/, lib/, mm/ and samples/ wait for rust/? >> That's a lot of stall: drivers/ is most of the tree. I think then a >> CONFIG_RUST build has most of its C work waiting on the rust chain; >> only the other top-level directories start early? This didn't create new >> build delays for those configurations? > > Yeah good point. > > For a defconfig+rust clean build on 128 threads the other top-level > directories > were done at ~14s while rust ran to ~18.6s, so there was 4-5 of idle. > > However the patch improves things by net -3.9s regardless. > > This is really only a big box issue though. With fewer threads the rest of the > tree takes longer so it has no impact on the build. > > (An aside - this kind of trade-off is what the series is all about really - > the > 'serial tail' - i.e. the single threaded stuff that _overlaps_ the end of the > build is what slows you down.) > > Since this _still_ gives you a significant speed up on bigger boxes, I think > it's fine as-is. > > The LLM says a fix for this would need significant work - a cross-instance > lock > and an on-demand rust/ build. So I think best as a follow-up?
If we do it we're basically reinventing a new build system. Not saying that Kbuild isn't one already :) Best, Gary
