From owner-freebsd-arch@FreeBSD.ORG Sun Mar 21 22:57:32 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 25F5316A4CE for ; Sun, 21 Mar 2004 22:57:32 -0800 (PST) Received: from t-axegw.t.axe-inc.co.jp (t-axegw.t.axe-inc.co.jp [218.230.241.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 209EF43D48 for ; Sun, 21 Mar 2004 22:57:31 -0800 (PST) (envelope-from tanimura@axe-inc.co.jp) Received: from shojaku.t.axe-inc.co.jp ([192.168.6.178]) id i2M6vDYI080595 ; Mon, 22 Mar 2004 15:57:14 +0900 (JST) Received: from shojaku.t.axe-inc.co.jp (localhost [127.0.0.1]) id i2M6vCrS097750 ; Mon, 22 Mar 2004 15:57:12 +0900 (JST) Message-Id: <200403220657.i2M6vCrS097750@shojaku.t.axe-inc.co.jp> Date: Mon, 22 Mar 2004 15:57:12 +0900 From: Seigo Tanimura To: John Baldwin In-Reply-To: <200403161009.48938.john@baldwin.cx> References: <200403160519.i2G5J0V6023193@urban> <200403161009.48938.john@baldwin.cx> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 MULE XEmacs/21.4 (patch 14) (Reasonable Discussion) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: arch@FreeBSD.org 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: Mon, 22 Mar 2004 06:57:32 -0000 On Tue, 16 Mar 2004 10:09:48 -0500, John Baldwin said: john> 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? john> We wouldn't be able to axe MTX_CONTEST. We also use it to determine on unlock john> if we can unlock easily or if we have waiters that we need to awake. The john> only way we might be able to axe MTX_CONTEST would be to penalize every john> unlock operation requiring a turnstile lookup (spin lock acquire/release + john> hash table lookup) even unlocks of an uncontested mutex. However, what I john> think you want to do is get rid of the mtx_lock == MTX_CONTESTED case and use john> turnstile_wakeup() rather than turnstile_signal()? Is that what you are Yes. What I an wondering is whether the reduction of the cost due to a mutex with waiters and no holders can beat the cost of waking up all the waiters on the turnstile. john> asking? That is something we can try at some point in the future, but we john> would need to benchmark both ways. What we might can do is add a kernel john> option MUTEX_WAKE_ALL or some such that uses the Solaris behavior. Having it john> be an option like ADAPTIVE_MUTEXES makes it easier to benchmark both cases. On the detection of the waiters by MTX_CONTEST, maybe we can test MTX_CONTEST on mtx_lock before performing _release_lock(). If the test succeeds, _mtx_unlock_sleep() must be called and we do not need to perform an atomic test-and-set. A race can occur if the mutex is locked after the MTX_CONTEST test, but _release_lock() should then cover the case. Pseudocode: mtx_unlock(m) { if (m->mtx_lock & MTX_CONTEST || !_release_lock(m)) _mtx_unlock_sleep(m); } -- Seigo Tanimura