From owner-freebsd-arch@FreeBSD.ORG Mon Mar 15 21:22:01 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 D639F16A4CE for ; Mon, 15 Mar 2004 21:22:01 -0800 (PST) Received: from sohgo.tanimura.dyndns.org (IP1A1374.kng.mesh.ad.jp [61.203.105.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24A2C43D45 for ; Mon, 15 Mar 2004 21:22:00 -0800 (PST) (envelope-from tanimura@tanimura.dyndns.org) Received: from sohgo.tanimura.dyndns.org (localhost [IPv6:::1]) ESMTP id i2G5LtlY017831 ; Tue, 16 Mar 2004 14:21:55 +0900 (JST) Received: (from uucp@localhost) (8.12.11/3.7W-submit-carrots-Tokyu-Meguro) with UUCP id i2G5LrcO017830 ; Tue, 16 Mar 2004 14:21:53 +0900 (JST) Received: from urban.nkth.tanimura.dyndns.org (localhost [IPv6:::1]) with ESMTP id i2G5J0V6023193 ; Tue, 16 Mar 2004 14:19:00 +0900 (JST) Message-Id: <200403160519.i2G5J0V6023193@urban> Date: Tue, 16 Mar 2004 14:19:00 +0900 From: Seigo Tanimura To: arch@FreeBSD.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 14) (Reasonable Discussion) (i386--freebsd) Organization: My Home MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: Seigo Tanimura Subject: 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 05:22:01 -0000 _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? -- Seigo Tanimura