On Wed, Sep 16, 2026 at 08:42:41AM +0100, Gary Guo wrote: > 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 :)
:) I mean arguably make is a seriously limiting factor in improvements (the other might be... C headers... but that's a whole other kettle of fish ;) > > Best, > Gary > -- Cheers, Lorenzo
