Date: Mon, 14 Jun 2004 21:39:42 +0200 From: Maxime Henrion <mux@freebsd.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: "David E. O'Brien" <obrien@FreeBSD.org> Subject: Re: cvs commit: src/sys/amd64/conf GENERIC Message-ID: <20040614193942.GD9228@elvis.mu.org> In-Reply-To: <20040614192422.GH61448@elvis.mu.org> References: <Pine.NEB.3.96L.1040614141907.34947B-100000@fledge.watson.org> <200406141458.02468.jhb@FreeBSD.org> <20040614192422.GH61448@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > * John Baldwin <jhb@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. Cheers, Maxime
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040614193942.GD9228>