From owner-cvs-src@FreeBSD.ORG Wed Nov 10 12:37:15 2004 Return-Path: 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 E270616A4CE; Wed, 10 Nov 2004 12:37:15 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3464443D2F; Wed, 10 Nov 2004 12:37:15 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])iAACb9KP003828; Wed, 10 Nov 2004 23:37:09 +1100 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) iAACb5CL017955; Wed, 10 Nov 2004 23:37:06 +1100 Date: Wed, 10 Nov 2004 23:37:06 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Scott Long In-Reply-To: <41910D86.3080605@freebsd.org> Message-ID: <20041110231010.O810@epsplex.bde.org> References: <4191062A.6090009@elischer.org> <1100024464.29384.30.camel@palm.tree.com> <41910D86.3080605@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 10 Nov 2004 12:49:31 +0000 cc: src-committers@FreeBSD.org cc: John Baldwin cc: Alan Cox cc: cvs-src@FreeBSD.org cc: Mike Silbersack cc: cvs-all@FreeBSD.org cc: Stephan Uphoff cc: Robert Watson cc: Julian Elischer Subject: Re: cvs commit: src/sys/i386/i386 pmap.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2004 12:37:16 -0000 On Tue, 9 Nov 2004, Scott Long wrote: > Stephan Uphoff wrote: > > On Tue, 2004-11-09 at 13:02, Julian Elischer wrote: > >>Can you explain why a spin mutex is more expensive than a sleep mutex (I > >>assume this is uncontested)? > > > > cli() and sti() used for the critical section are expensive. > > ( The spin mutex includes the critical section) > > > > I recall a USENIX paper about avoiding the cost of cli(),sti() by just > > setting an in memory flag. The interrupt handler was modified to honor > > the flag and delay interrupt processing until the flag was cleared. > > This may have the potential to drastically decrease the cost of a spin > > mutex if interrupts during critical regions are infrequent. > > You mean create a word, let's just call it an 'intrmask_t', that can be > set and cleared by the OS and drivers, and checked in the interrupt > handler to see if the interrupt should be serviced right away or not? > Hmmm... we'd have to think up a name for the API..... hmmmm... maybe > spl()? That is the FreeBSD-[1-4] way. It is a little different since it has an array of flags (one for each interrupt). In -current on i386's between rev.1.2 (2002/07/10) and 1.5 (2003/11/03) of , the flag was named curthread->td_critnest. intrmask_t's were still used, but only to record the deferred interrupts. Bruce