From owner-cvs-src@FreeBSD.ORG Sun Jul 3 01:16:49 2005 Return-Path: <owner-cvs-src@FreeBSD.ORG> X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C34FB16AF68; Sun, 3 Jul 2005 00:59:35 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6546B442A6; Sun, 3 Jul 2005 00:45:49 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 543596E190; Sat, 2 Jul 2005 17:39:06 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id 9EE015CA52 for <ps@mu.org>; Thu, 11 Nov 2004 08:15:06 -0800 (PST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id BEBC85897C for <ps@mu.org>; Thu, 11 Nov 2004 16:13:57 +0000 (GMT) (envelope-from owner-src-committers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id 3408916A567; Thu, 11 Nov 2004 16:13:42 +0000 (GMT) Delivered-To: ps@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id F087316A4E7; Thu, 11 Nov 2004 16:13:38 +0000 (GMT) Delivered-To: src-committers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C167716A4DB for <src-committers@FreeBSD.org>; Thu, 11 Nov 2004 16:13:35 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46DDC43D49 for <src-committers@FreeBSD.org>; Thu, 11 Nov 2004 16:13:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20739 invoked from network); 11 Nov 2004 16:13:35 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender <jhb@FreeBSD.org>) by mail4.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <cvs-all@FreeBSD.org>; 11 Nov 2004 16:13:34 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iABGDLDc044012; Thu, 11 Nov 2004 11:13:31 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin <jhb@FreeBSD.org> To: David Schultz <das@FreeBSD.org> User-Agent: KMail/1.6.2 References: <200410311932.i9VJWvmo058193@repoman.freebsd.org> <200411081311.42201.jhb@FreeBSD.org> <20041108223339.GA29876@VARK.MIT.EDU> In-Reply-To: <20041108223339.GA29876@VARK.MIT.EDU> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411100919.01103.jhb@FreeBSD.org> Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on elvis.mu.org X-Spam-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48 autolearn=no version=3.0.0 X-Spam-Level: Cc: Alan Cox <alc@FreeBSD.org>, cvs-src@FreeBSD.org, Alfred Perlstein <alfred@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_zeroidle.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>, <mailto:cvs-src-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/cvs-src> List-Post: <mailto:cvs-src@freebsd.org> List-Help: <mailto:cvs-src-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>, <mailto:cvs-src-request@freebsd.org?subject=subscribe> Date: Sun, 03 Jul 2005 01:16:49 -0000 X-Original-Date: Wed, 10 Nov 2004 09:19:01 -0500 X-List-Received-Date: Sun, 03 Jul 2005 01:16:49 -0000 On Monday 08 November 2004 05:33 pm, David Schultz wrote: > On Mon, Nov 08, 2004, John Baldwin wrote: > > > The mutex associated with the condition variable will be held on > > > entry to both cv_wait() and cv_signal(), so why is the sleepqueue > > > locked in the no waiters case? > > > > It is no longer required to hold the mutex over cv_wait() and > > cv_signal(). I intentionally changed that so that you can do: > > > > lock() > > blah() > > unlock() > > cv_signal() > > > > and reduce the number of context switches if you preempt in cv_signal(). > > Hmm...I agree with Alfred that allowing this is a bad idea. By > permitting this, you're adding two additional mutex operations to > the critical path in order to avoid an inefficiency that will > almost never occur. Actually, it would always occur on a UP system if you preempt in the signal/broadcast. FWIW, I've specifically had other people ask for this "feature". Note that this also now allows you to do things like 'cv_signal()' from a fast interrupt handler if needbe. > Suppose that the cv_signal() is done immediately *before* the unlock > operation. The odds that the signalling thread is preempted in a > the few cycles between the cv_signal() and the unlock are close to > nil. Furthermore, on a multiprocessor, it will take longer for > another processor to schedule one of the waiters than it will for > the signalling processor to release the lock. Since setrunqueue() itself can preempt now, the odds are higher than you might think. > The original formulation of this kind of condition variable was in > Mesa[1], which requires the lock to be held during cv_signal() > specifically for efficiency.[2] Solaris also requires the mutex to > be held across cv_signal(). PThreads is the only API I know of to > have it the other way around. > > > [1] http://research.microsoft.com/Lampson/23-ProcessesInMesa/WebPage.html > > [2] It supported a second, less efficient type of CV that would > allow device microcode to signal device drivers without > holding the mutex, but all other CVs required the mutex to be > held when the CV was signalled. But this second kind of CV > is irrelevant today. Well, it is easy enough to back out if the differering opinions on the subject can reach a consensus. There was a discussion on smp@ a while back in favor of allowing cv_signal/broadcast to not require the mutex to be held there earlier. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org