From owner-cvs-all@FreeBSD.ORG Sun Jul 3 01:15:56 2005 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FAF316AB65; 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 5DA91442C4; Sun, 3 Jul 2005 00:45:51 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 1A3226E108; Sat, 2 Jul 2005 17:39:07 -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 F29435C967 for ; Thu, 11 Nov 2004 09:04:56 -0800 (PST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id C903B582C6 for ; Thu, 11 Nov 2004 17:04:56 +0000 (GMT) (envelope-from owner-src-committers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id 2F7FF16A4E7; Thu, 11 Nov 2004 17:04:46 +0000 (GMT) Delivered-To: ps@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 96A7B16A4D1; Thu, 11 Nov 2004 17:04:43 +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 1971616A4CE; Thu, 11 Nov 2004 17:04:42 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADBC743D49; Thu, 11 Nov 2004 17:04:41 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.1/8.13.1/NETPLEX) with ESMTP id iABH4e0X008080; Thu, 11 Nov 2004 12:04:40 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200411100919.01103.jhb@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) 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=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.0 X-Spam-Level: Cc: src-committers@freebsd.org, Alan Cox , cvs-src@freebsd.org, Alfred Perlstein , cvs-all@freebsd.org, David Schultz Subject: Re: cvs commit: src/sys/vm vm_zeroidle.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: Daniel Eischen List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 01:15:56 -0000 X-Original-Date: Thu, 11 Nov 2004 12:04:40 -0500 (EST) X-List-Received-Date: Sun, 03 Jul 2005 01:15:56 -0000 On Wed, 10 Nov 2004, John Baldwin wrote: > On Monday 08 November 2004 05:33 pm, David Schultz wrote: > > On Mon, Nov 08, 2004, John Baldwin wrote: > > > 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. > [ ... ] > > 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. I think the reason Solaris can enforce that you hold the mutex around cv_signal() and cv_broadcast() is that it knows if the mutex is used by an interrupt handler. You must initialize mutexes with the registered interrupt iblock cookie if they are going to be used by an interrupt handler, so the system can handle these mutexes specially when non-ISR code holds them. I think this allows the ISR to take the mutex without suffering the penalty of blocking when the mutex is locked. Since there is no similar knowledge in our mutexes/CVs, I think it makes sense to allow cv_signal() and cv_broadcast() without holding the lock (similar to sem_post() being signal safe). -- DE