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?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
