On Thu, Nov 14, 2024 at 11:05:16AM +0000, Martin Pieuchot wrote:
> On 08/11/24(Fri) 13:01, Stuart Henderson wrote:
> > On 2024/11/08 13:26, Martin Pieuchot wrote:
> > > On 08/11/24(Fri) 12:22, Landry Breuil wrote:
> > > > [...] 
> > > > someone(tm) should look into patching lld to avoid using more than
> > > > MAX(ncpu,5) threads ? In the meantime, i'll probably fix the firefox
> > > > ports to avoir using MAKE_JOBS for lld but cap it at 5.
> > > 
> > > Recent lld(1) include the following commits which limit the value to
> > > 16 by default instead of the number of available CPUs.
> > > 
> > > See the following commits:
> > > 
> > > https://github.com/llvm/llvm-project/commit/a8788de1c3f3c8c3a591bd3aae2acee1b43b229a
> > > https://github.com/llvm/llvm-project/commit/da68d2164efcc1f5e57f090e2ae2219056b120a0
> > > 
> > > Robert do you see the same with chromium?  Would it make sense to
> > > backport these diff with a smaller value for OpenBSD?
> > > 
> > 
> > Certainly helps for reorder_kernel.
> 
> It also helps for any configure script.
> 
> The one from wget I'm currently playing with is 2 times slower on a
> 24CPUs machine with GENERIC.MP than with GENERIC. 
> 
> FlameGraph attached corresponds to non-idle time spent in kernel during
> the execution of the wget configure script.  ~20% of sys time is spent
> in sys_futex/rw_lock contention which correspond lld(1) threads spinning.

16 is still way too high of a count -- vast majority of binaries have
little to gain from parallel linking to begin with and lld itself does
not scale all the great either. Finally, if there are multiple llds
running at the same time (think parallel port build or system build)
that's just plain waste.

See this for some measurements: https://discourse.llvm.org/t/avoidable-overhead-from-threading-by-default/69160

In FreeBSD I patched it down to 4 threads at most by default. The
--threads parameter can be used to override it.