Re: [PATCH v2 20/21] kbuild: build rust crates in parallel with the rest of the build

From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Gary Guo <gary@garyguo.net>
Cc: "Kees Cook" <kees@kernel.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nicolas Schier" <nsc@kernel.org>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Bill Wendling" <morbo@google.com>,
	"Justin Stitt" <justinstitt@google.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Alexey Gladkov" <legion@kernel.org>,
	"Thomas Gleixner" <tglx@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Paul Walmsley" <pjw@kernel.org>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	llvm@lists.linux.dev, linux-riscv@lists.infradead.org,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-efi@vger.kernel.org, rust-for-linux@vger.kernel.org,
	linux-doc@vger.kernel.org, "Jens Axboe" <axboe@kernel.dk>,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2 20/21] kbuild: build rust crates in parallel with the rest of the build
Date: Wed, 16 Sep 2026 15:03:21 +0100	[thread overview]
Message-ID: <aqqhKFuclruH3lXn@gremlin> (raw)
In-Reply-To: <DLGKLQ9LJPBG.3QU14CCO1Y6Q@garyguo.net>

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