Date: Mon, 7 Jun 2004 08:27:21 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-hackers@FreeBSD.org Cc: Ali Niknam <ali@transip.nl> Subject: Re: FreeBSD 5.2.1: Mutex/Spinlock starvation? Message-ID: <200406070827.21333.jhb@FreeBSD.org> In-Reply-To: <00da01c44b3f$74d3d8c0$0400a8c0@redguy> References: <Pine.NEB.3.96L.1040604153442.34555O-100000@fledge.watson.org> <00da01c44b3f$74d3d8c0$0400a8c0@redguy>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406070827.21333.jhb>