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.