Re: [PATCH v2 21/21] kbuild: use pigz for gzip compression if available

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Tue, Sep 15, 2026 at 08:02:38PM +0200, Arnd Bergmann wrote:
> On Tue, Sep 15, 2026, at 19:47, Nick Desaulniers wrote:
> > On Tue, Sep 15, 2026 at 10:31 AM Kees Cook <kees@kernel.org> wrote:
> >> On Tue, Sep 15, 2026 at 03:30:43PM +0100, Lorenzo Stoakes (ARM) wrote:
> >> a)
> >> My main concern is the lack of respecting the -j make argument. In my
> >> mind, this is a blocker, because it means a build will now _always_ spin
> >> up max CPUs (not what -j has limited it to), and for CIs, shared compute
> >> systems, or whatever, this violates the requested parallelism level. For
> >> example, if I'm doing a long-running Coccinelle replacement in one tree
> >> (which uses half the CPUs), any builds I launch I'm asking for the other
> >> half of my CPUs to be used so they don't thrash my cache.
> >>
> >> This is the kind of "why are all the CPUs spinning up?" question I
> >> helped track down with commit 51e46c7a4007 ("docs, parallelism: Rearrange
> >> how jobserver reservations are made") forever ago.
> >
> > Parse -j from MAKEFLAGS (https://stackoverflow.com/a/76517886),
> > forward it to pigz?
>
> That still has a potential O(n²) problem: if one builds N kernels
> with a top-level jobserver on N CPUs, and they all take the same
> amount of time, you end up with N pigz processes each trying to use
> N cpus at the same time. Ideally we'd use the equivalent of
> -flto=auto in the compiler, which respects jobserver settings,
> but I don't think pigz supports this at the moment.

Hmm this is a good point :) though I see Kees has made a suggestion that
could solve all of these concerns!

>
>       Arnd

--
Cheers, Lorenzo