From owner-cvs-all@FreeBSD.ORG Mon Jun 14 19:48:58 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EFF416A4DD; Mon, 14 Jun 2004 19:48:58 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB97143D1F; Mon, 14 Jun 2004 19:48:57 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B58DC5C82F; Mon, 14 Jun 2004 12:48:36 -0700 (PDT) Date: Mon, 14 Jun 2004 12:48:36 -0700 From: Alfred Perlstein To: Maxime Henrion Message-ID: <20040614194836.GJ61448@elvis.mu.org> References: <200406141458.02468.jhb@FreeBSD.org> <20040614192422.GH61448@elvis.mu.org> <20040614193942.GD9228@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040614193942.GD9228@elvis.mu.org> User-Agent: Mutt/1.4.2.1i cc: src-committers@FreeBSD.org cc: John Baldwin cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Robert Watson cc: "David E. O'Brien" Subject: Re: cvs commit: src/sys/amd64/conf GENERIC X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 19:48:58 -0000 * Maxime Henrion [040614 12:40] wrote: > Alfred Perlstein wrote: > > * John Baldwin [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 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. === Just an interesting idea. -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684