From owner-cvs-all@FreeBSD.ORG Thu Nov 11 21:32:18 2004 Return-Path: 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 F014316A4CE; Thu, 11 Nov 2004 21:32:18 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 978F343D31; Thu, 11 Nov 2004 21:32:16 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id iABLWOB6005300; Thu, 11 Nov 2004 16:32:24 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id iABLWOXg005299; Thu, 11 Nov 2004 16:32:24 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 11 Nov 2004 16:32:24 -0500 From: David Schultz To: John Baldwin Message-ID: <20041111213224.GA5239@VARK.MIT.EDU> Mail-Followup-To: John Baldwin , Alfred Perlstein , Alan Cox , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200410311932.i9VJWvmo058193@repoman.freebsd.org> <200411081311.42201.jhb@FreeBSD.org> <20041108223339.GA29876@VARK.MIT.EDU> <200411100919.01103.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411100919.01103.jhb@FreeBSD.org> cc: Alan Cox cc: cvs-src@FreeBSD.ORG cc: Alfred Perlstein cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_zeroidle.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 21:32:19 -0000 On Wed, Nov 10, 2004, John Baldwin wrote: > > 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. There's always the possibility of providing two types of condition variables as in Mesa, one of which is capable of performing a ``naked notify'', as Lampson calls it. > > 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. Yeah, if there is an explicit yield, that could be a problem. Priority propagation for CVs might help, but the right answer to that problem is probably to have a way to make a thread runnable without yielding. > 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 have no intent of going on a war path against the current semantics (particularly given how little time I have for kernel hacking these days.) But it doesn't seem to me that the choice that was made is the correct one. Synchronization primitives should be lightweight enough that people don't need to invent ad hoc ones of their own to avoid ``expensive cv_wakeup() calls'' and so forth.