From: Martin Pieuchot <mpi@grenadille.net>
Subject: Re: Upper bound for mtx_enter() exp. backoff
To: Ted Unangst <tedu@tedunangst.com>
Cc: tech@openbsd.org
Date: Sat, 7 Jun 2025 11:20:25 +0200

On 06/06/25(Fri) 16:43, Ted Unangst wrote:
> On 2025-06-06, Martin Pieuchot wrote:
> > Turns out 64 is not enough to completely prevent hangs on Ampere Altra
> > with 80 CPUs.
> > 
> > Instead of using a magic number pick the number of CPUs online.  On the
> > Altra with 80 CPUs this makes the upper bound at 128.  Using the number
> > of available CPUs should also reduce latency on smaller SMP machines.
> > 
> > With this I can purposely generate contention on the Ampere machine.
> > 
> > ok?
> 
> Should it be found or online? And should you shadow it locally?

Can I get the fix in before we start optimizing it?

> > Index: kern/kern_lock.c
> > ===================================================================
> > RCS file: /cvs/src/sys/kern/kern_lock.c,v
> > diff -u -p -r1.78 kern_lock.c
> > --- kern/kern_lock.c	31 May 2025 10:24:50 -0000	1.78
> > +++ kern/kern_lock.c	3 Jun 2025 08:25:31 -0000
> > @@ -37,6 +37,8 @@
> >  int __mp_lock_spinout = INT_MAX;
> >  #endif /* MP_LOCKDEBUG */
> >  
> > +extern int ncpusfound;
> > +
> >  /*
> >   * Min & max numbers of "busy cycles" to waste before trying again to
> >   * acquire a contended lock using an atomic operation.
> > @@ -50,7 +52,7 @@ int __mp_lock_spinout = INT_MAX;
> >   * enough to reduce (ideally avoid) cache line contention.
> >   */
> >  #define CPU_MIN_BUSY_CYCLES	1
> > -#define CPU_MAX_BUSY_CYCLES	64
> > +#define CPU_MAX_BUSY_CYCLES	ncpusfound
> >  
> >  #ifdef MULTIPROCESSOR
> >  
> > 
> > 
> >