From owner-cvs-all@FreeBSD.ORG Tue Nov 9 18:40:36 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 780ED16A81A for ; Tue, 9 Nov 2004 18:40:36 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 14DFC43D41 for ; Tue, 9 Nov 2004 18:40:35 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 24809 invoked by uid 89); 9 Nov 2004 18:40:32 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 9 Nov 2004 18:40:32 -0000 Received: (qmail 24728 invoked by uid 89); 9 Nov 2004 18:40:32 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 9 Nov 2004 18:40:32 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id iA9IeW5R030144; Tue, 9 Nov 2004 13:40:32 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Scott Long In-Reply-To: <41910D86.3080605@freebsd.org> References: <1100024464.29384.30.camel@palm.tree.com> <41910D86.3080605@freebsd.org> Content-Type: text/plain Message-Id: <1100025632.29384.54.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 09 Nov 2004 13:40:32 -0500 Content-Transfer-Encoding: 7bit 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: Robert Watson cc: Julian Elischer Subject: Re: cvs commit: src/sys/i386/i386 pmap.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: Tue, 09 Nov 2004 18:40:36 -0000 On Tue, 2004-11-09 at 13:33, Scott Long wrote: > Stephan Uphoff wrote: > > On Tue, 2004-11-09 at 13:02, Julian Elischer wrote: > > > >>Robert Watson wrote: > >> > >> > >>>This change made a large difference, and eliminates the unexplained costs. > >>>Here's a revised table as compared to the above: > >>> > >>> sleep mutex crit section spin mutex new spin mutex > >>> UP SMP UP SMP UP SMP UP SMP > >>>PIII 21 81 83 81 112 141 95 141 > >>>P4 39 260 120 119 274 342 132 231 > >>> > >>>So it basically cut 140 cycles off the P4 UP spin lock, 15 off the PIII UP > >>>spin lock, and 110 cycles off the P4 SMP spin lock. The PIII SMP spin > >>>lock looks the same. Keep in mind that all of these measurements have a > >>>standard deviation of between 0 and 3 cycles, most in the 1 range. Also > >>>keep in mind that these are entirely uncontended measurements. > >>> > >>>Assuming that these changes are correct, and pass whatever tests people > >>>have in mind, this would be a very strong merge candidate for performance > >>>reasons. The difference is visible in packet send tests from user space > >>>as a percentage or two improvement on UP on my P4, although it's a litte > >>>hard to tell due to the noise. > >>> > >>> > >> > >>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. > > > > Stephan > > > > 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()? > > =-) > > Scott Caugh, caugh ... yes that would be a fine name .... caugh, caugh ;-) Stephan