FreeBSD 5.2.1: Mutex/Spinlock starvation?
jhb at FreeBSD.org
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
> - 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 FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-hackers