Re: [PATCH v2 18/21] kbuild: rust: optionally parallelise rustc front end

[Lorenzo Stoakes (ARM)]

On Tue, Sep 15, 2026 at 12:09:04PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Mon, Sep 14, 2026 at 11:32:14AM -0700, Kees Cook wrote:
> > On Mon, Sep 14, 2026 at 10:22:17AM +0100, Lorenzo Stoakes (ARM) wrote:
> > > The threads are taken from make's jobserver, so a parallel build is not
> > > oversubscribed. It was found that benefits level off at 8 threads (16 was
> > > found to be around the same, and 32 slower).
> >
> > I think it's worth noting that this comes from rustc itself (it has
> > built-in support for the make jobserver). See commit ecab4115c44c
> > ("kbuild: mark `rustc` (and others) invocations as recursive").
> >
> > What happens when there is no jobserver, e.g. "make" without -j, or
> > "make -j1"?
> >
> > > [...]
> > > 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
> > > [...]
> > > +The number of threads rustc's parallel front end may use, passed to it as
> > > +``-Zthreads``. Unset by default, as the parallel front end is not yet
> > > +stable and its output is not reproducible. The gain levels off at 8
> > > +threads.
> >
> > Okay, unstable, not reproducible.
> >
> > > Generated output was confirmed byte-for-byte identical.
> >
> > But this says otherwise? I am confused. Reproducible or not?

On this though - the lack of reproducibility was the reports in the rust world
of the -Zthreads flag sometimes resulting in that.

I never observed that locally at all, and so locally it was all byte-for-byte
identical.

It could have been worded better :)

>
> Well, we can set all of this aside as, based on Miguel's feedback, I think
> dropping this commit is best :)
>
> >
> > --
> > Kees Cook
>
> --
> Cheers, Lorenzo

--
Cheers, Lorenzo