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 <[email protected]> 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
