Date: Tue, 23 Mar 2004 21:46:26 +0300 (MSK) From: Maxim Konovalov <maxim@macomnet.ru> To: John Baldwin <jhb@FreeBSD.org> Cc: Seigo Tanimura <tanimura@tanimura.dyndns.org> Subject: ADAPTIVE_MITEXES (Was: Is MTX_CONTESTED evil?) Message-ID: <20040323214327.A46706@mp3files.int.ru> In-Reply-To: <200403231026.24155.jhb@FreeBSD.org> References: <200403160519.i2G5J0V6023193@urban> <200403221906.47238.john@baldwin.cx> <200403231026.24155.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ CC'ed the box owner ] On Tue, 23 Mar 2004, 10:26-0500, John Baldwin wrote: > On Monday 22 March 2004 11:40 pm, Maxim Konovalov wrote: > > On Mon, 22 Mar 2004, 19:06-0500, John Baldwin wrote: > > > > [...] > > > > > > By the way, one thing to keep in mind is that Solaris has working > > > > adaptive mutexes. For adaptive mutexes, the waiting case is > > > > almost never supposed to happen, so it's more reasonable for them > > > > to wake all waiters. However, AFAIK, FreeBSD's adaptive mutex > > > > support is incomplete or broken at this point, so you may run into > > > > a thundering herd problem if you wake all waiters. > > > > > > Adaptive mutexes work just fine, but they aren't on by default. In > > > FreeBSD, adaptive mutexes spin so long as the owner is still executing on > > > another CPU. > > > > With 'options ADATIVE_MUTEXES' our SMP testbox crashes very reliable. > > If you are interested in a traceback and/or crashdump let me know. > > I can look at it. The bug is likely in some other code that is not really MP > safe but is out from under Giant anyways as adaptive mutexes allow more > concurrent execution and thus expose a lot more races. OK, we rebuilt the kernel with 'options ADAPTIVE_MUTEXES' and now running our usual stress testes. Hope will get a crashdump soon. -- Maxim Konovalov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040323214327.A46706>