From owner-cvs-all@FreeBSD.ORG Tue Nov 9 18:21:10 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 DD40616A4D2 for ; Tue, 9 Nov 2004 18:21:10 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 455AB43D54 for ; Tue, 9 Nov 2004 18:21:10 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 469 invoked by uid 89); 9 Nov 2004 18:21:06 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 9 Nov 2004 18:21:06 -0000 Received: (qmail 408 invoked by uid 89); 9 Nov 2004 18:21:05 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 9 Nov 2004 18:21:05 -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 iA9IL45R029978; Tue, 9 Nov 2004 13:21:05 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <4191062A.6090009@elischer.org> References: <4191062A.6090009@elischer.org> Content-Type: text/plain Message-Id: <1100024464.29384.30.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 09 Nov 2004 13:21:04 -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 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:21:11 -0000 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