[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-arch
Subject:    ADAPTIVE_MITEXES (Was: Is MTX_CONTESTED evil?)
From:       Maxim Konovalov <maxim () macomnet ! ru>
Date:       2004-03-23 18:46:26
Message-ID: 20040323214327.A46706 () mp3files ! int ! ru
[Download RAW message or body]

[ 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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]