From owner-freebsd-arch@FreeBSD.ORG Tue Mar 16 08:06:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0D4816A4CE for ; Tue, 16 Mar 2004 08:06:12 -0800 (PST) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15F3443D2D for ; Tue, 16 Mar 2004 08:06:12 -0800 (PST) (envelope-from john@baldwin.cx) Received: (qmail 12782 invoked from network); 16 Mar 2004 16:06:09 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 16 Mar 2004 16:06:09 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i2GG5m28065141; Tue, 16 Mar 2004 11:05:49 -0500 (EST) (envelope-from john@baldwin.cx) From: John Baldwin To: arch@FreeBSD.org Date: Tue, 16 Mar 2004 10:09:48 -0500 User-Agent: KMail/1.6 References: <200403160519.i2G5J0V6023193@urban> In-Reply-To: <200403160519.i2G5J0V6023193@urban> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403161009.48938.john@baldwin.cx> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Seigo Tanimura Subject: Re: Is MTX_CONTESTED evil? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 16:06:12 -0000 On Tuesday 16 March 2004 12:19 am, Seigo Tanimura wrote: > _mtx_unlock_sleep() currently wakes up only one thread being blocked, > and leaves MTX_CONTESTED on a mutex. According to Solaris Internals, > that strategy adds an overhead to check for MTX_CONTESTED on a mutex, > even though it is not held by any thread. The thread waken up cannot > grab the mutex immediately by _obtain_lock() and have to go through > _mtx_lock_sleep(). The penalty tends to be large for a mutex with a > high contention, and we have at least one of such a mutex - Giant. > > What would it be like if we axed MTX_CONTEST and let > _mtx_unlock_sleep() wake up all of the blocked threads? We wouldn't be able to axe MTX_CONTEST. We also use it to determine on unlock if we can unlock easily or if we have waiters that we need to awake. The only way we might be able to axe MTX_CONTEST would be to penalize every unlock operation requiring a turnstile lookup (spin lock acquire/release + hash table lookup) even unlocks of an uncontested mutex. However, what I think you want to do is get rid of the mtx_lock == MTX_CONTESTED case and use turnstile_wakeup() rather than turnstile_signal()? Is that what you are asking? That is something we can try at some point in the future, but we would need to benchmark both ways. What we might can do is add a kernel option MUTEX_WAKE_ALL or some such that uses the Solaris behavior. Having it be an option like ADAPTIVE_MUTEXES makes it easier to benchmark both cases. -- John Baldwin <>< http://www.baldwin.cx/~john/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org