From owner-freebsd-current@FreeBSD.ORG Mon Feb 26 23:42:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A501516A563; Mon, 26 Feb 2007 23:42:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2BBE913C428; Mon, 26 Feb 2007 23:42:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l1QNgb7X044454; Mon, 26 Feb 2007 18:42:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Feb 2007 18:39:36 -0500 User-Agent: KMail/1.9.1 References: <20070224213111.GB41434@xor.obsecurity.org> <20070225105220.N36322@fledge.watson.org> In-Reply-To: <20070225105220.N36322@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702261839.36971.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Feb 2007 18:42:51 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2656/Mon Feb 26 15:24:59 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Robert Watson , Ivan Voras Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 23:42:58 -0000 On Sunday 25 February 2007 05:56, Robert Watson wrote: > On Sun, 25 Feb 2007, Ivan Voras wrote: > > > Kris Kennaway wrote: > > > >> Hopefully within a week or two. It might not be that exact patch, I > >> think John wants to try and do it a bit differently instead of > >> introducing a new locking primitive just for this. > > > > Well why not? :) I am not an expert, but reading jeffr's posts it looks like > > the idea of sleepable mutexes was taken from Solaris, where it's also not > > exactly documented. If moving away from sleepable mutexes introduces more > > than a small single digit percentage drop in performance (1% on > > multi-gigahertz machines is a lot), why not keep it? If it's dangerous to > > use, that should be documented in the man page with big bold letters but if > > it helps, keep it. > > > > (Of course I might be completely off the track and sleepable mutexes might > > be inconsequential for performance here :) ) > > Well, there are two ways you can ask the question about locks here: > > (1) Why don't we allow sleeping with mutexes? > > (2) Why don't the sleepable locking primitives perform better? > > There are now patches that address this from both sides, optimizing sx lock > performance and allowing mutexes to sleep. There are serious deadlock issues > that can arise with sleepable mutexes; I believe Jeff's patch includes the > necessary bits to teach WITNESS how to detect some misuse at run-time. Right > now, with the exception of the fast interrupt context, mutexes are universally > acquirable in any context subject to lock order. If we have sleepable > mutexes, this will no longer be true, which is a significant change in the > constraints on use. Attilio has a heavily optimized sxlock implementation as > well, although I'm not sure the two have been benchmarked side-by-side, but > that would be an obvious next thing to try. My intention is to both get the sx locks changes into the tree so that sx locks use atomic ops, and to add a new sleep lock primitive that is like a mutex but uses sleepq rather than turnstiles. The latter is a lot like Jeff's top-half mutex just with some slight tweaks, and as a separate lock primitive. -- John Baldwin