Re: [PATCH v2 17/21] objtool: decode instructions and resolve branch targets in parallel

[Lorenzo Stoakes (ARM)]

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)" <ljs@xxxxxxxxxx> 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