On Tue, Sep 15, 2026 at 12:29:59PM +0100, David Laight wrote: > On Tue, 15 Sep 2026 11:09:25 +0100 > "Lorenzo Stoakes (ARM)" <[email protected]> wrote: > > > > > +static unsigned int decode_threads(unsigned long text_size) > > > > +{ > > > > + const long nr_cpus = sysconf(_SC_NPROCESSORS_ONLN); > > > > + > > > > + if (text_size < DECODE_THREADED_MIN_TEXT || nr_cpus < 2) > > > > + return 1; > > The text_size check ought to be before the sysconf() call.
This is bordering on a silly level of micro-optimisation :) This is ~us runtime, run once. We can live with it. > > > > > + > > > > + return min_t(unsigned int, nr_cpus, DECODE_MAX_THREADS); > > Why min_t() - you might as well make nr_cpus 'unsigned int'. Except... sysconf() returns a long and -1 on error. Isn't min_t() explicitly for cases like this? > > > > > +} > > > > > > No, anything using _SC_NPROCESSORS_ONLN internally is wrong, whether its > > > pigz or objtool. > > > > Why? We shouldn't cap a 4 CPU box to 4 CPUs? > > You almost certainly don't want to use more... > (Unless they end up waiting for disk) Yup on the former. > > > > > The idea is that the empirically obtained 16 core limit should naturally be > > capped to the number of CPUs. > > The 'empirical' limit is very likely to be system dependant. This same objection could be made against literally anything I do or do not do, it's a little silly. Every single cap like this is heuristic and limited. In any case - for smaller machines, the cap will be CPU count, on larger machines 16 CPUs is where there stops being an noticeable benefit. Other solutions are strictly worse, this is a sensible, practical engineering solution. > There might also be situations where you don't want the build to run as fast > as possible because the system is performing other workloads. Umm what? It's 2026, schedulers are pretty good now :) In any case with the changes here objtool doesn't dominate the runtime, so it'll have little impact. So run make j=1 to your heart's content :) > (Not to mention if you have had to add tracing to find a bug.) This is almost an argument against parallelism in general. > > > > > I guess in a world where make hands jobs off this could be dropped, though, > > if the complexity there seems worthwhile. > > You need to pull tokens out of the make pipe :-) Thanks, I understand what's required, as I said to Kees there's simply no benefit for the added complexity. Series like this can die by 1,000 cuts with all the nitpicks and what if's, let's focus on the _significant_ improvements introduced here and keep things in perspective please! > > David > -- Cheers, Lorenzo
