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

[Arnd Bergmann]

On Tue, Sep 15, 2026, at 19:47, Nick Desaulniers wrote:
> On Tue, Sep 15, 2026 at 10:31 AM Kees Cook <kees@xxxxxxxxxx> 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.

      Arnd