cvs commit: src/sys/amd64/conf GENERIC

[Daniel Eischen]

On Mon, 14 Jun 2004, Alfred Perlstein wrote:

> * Maxime Henrion <mux at freebsd.org> [040614 12:40] wrote:
> > Alfred Perlstein wrote:
> > > * John Baldwin <jhb at FreeBSD.org> [040614 11:57] wrote:
> > > > 
> > > > I'm betting it is just triggering a race.  When I first did the adaptive 
> > > > mutexes I stress tested it (-j <bignum> buildworld loops) on an ultra60, an 
> > > > alpha ds20, and a quad pii-xeon w/o any lockups.
> > > 
> > > Just a side note, I think it's the Berkeley DB's recent code that
> > > will spin a number of times based on the number of CPUs present in
> > > the system.  Meaning, it might make sense to spin more on a quad
> > > than on a dual proc machine.  It might be worth checking this out.
> > 
> > What do you mean by spinning more?  As far as I know, with adaptive
> > mutexes, if some thread tries to lock a blocking mutex that is already
> > held by another thread currently running on another CPU, then it spins
> > instead of blocking, assuming the other thread will soon release the
> > mutex.  Obviously, this has more chances to happen if there are more
> > CPUs in the system but I don't get what you mean here.
> 
> 
>  DbEnv::set_tas_spins
> 
>    Specify that test-and-set mutexes should spin tas_spins times without
>    blocking. The value defaults to 1 on uniprocessor systems and to 50
>    times the number of processors on multiprocessor systems.
> 
>    The database environment's test-and-set spin count may also be set
>    using the environment's DB_CONFIG file. The syntax of the entry in
>    that file is a single line with the string "set_tas_spins", one or
>    more whitespace characters, and the number of spins. Because the
>    DB_CONFIG file is read when the database environment is opened, it
>    will silently overrule configuration done before that time.

I think you're missing his point.  Adaptive mutexes _do_ spin.
The optimization is that they spin for only as long as the
current owner is running (on another CPU).  If the owner is
not running or stops running, the thread blocks.

The kernel knows about its threads, which thread owns a
mutex, and whether that thread is running.  And since
the desire is for mutexes to be held for short periods, it
is better for the requesting thread to spin as long as the
owning thread is running.  And conversely, it doesn't make
sense to spin if the owning thread isn't running.

-- 
DE