FreeBSD 5.2.1: Mutex/Spinlock starvation?

John Baldwin jhb at
Mon Jun 7 12:26:37 GMT 2004

On Saturday 05 June 2004 04:55 pm, Ali Niknam wrote:
> Hi Robert,
> As promised my findings regarding the changes; just came home after a night
> of trying and praying :)
> > Actually, by default, most mutexes in the system are sleep mutexes, so
> > they sleep on contention rather than spinning.  In some cases, this
> > actually hurts more than spinning, because if the mutex is released
> > quickly by the holder, then you pay the context switches which cost
> > more than spinning for the short period of time.
> >
> > You might want to try adding "options ADAPTIVE_MUTEXES" to your kernel
> > configuration, which will cause mutexes to spin briefly on SMP systems
> > before sleeping, and has been observed to improve performance quite a
> > bit.
> I tried this; this helps performance a lot, here are the findings:
>  - under all conditions turning on HTT helps a *lot* (which is logical i
> think)
>  - under non killing load (killing load = load where server would have
> crashed without this option) it performs much much better
>  - under killing load it performs a lot better, up until a certain level:
>  - a new killing level: from this point onward basically the same thing
> happens as before..
> What i'm guessing is that probably this new killing level occurs when load
> is so high that the spins 'adapt' into blocks. From your description above
> I understand that there's a certain timeout when 'spinning' mutexes turn
> into 'blocking'/'sleeping' mutexes. Is there a way to set this timeout ? I
> would very much like to try out what would happen if one would set this
> timeout to a quite high value.

There isn't a timeout.  Rather, the lock spins so long as the current owning 
thread is executing on another CPU.

John Baldwin <jhb at>  <><
"Power Users Use the Power to Serve"  =

More information about the freebsd-hackers mailing list