From owner-cvs-all@FreeBSD.ORG Tue Nov 9 18:32:52 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 E161016A4CE; Tue, 9 Nov 2004 18:32:52 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C9343D46; Tue, 9 Nov 2004 18:32:52 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iA9IZDe8054067; Tue, 9 Nov 2004 11:35:13 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41910D86.3080605@freebsd.org> Date: Tue, 09 Nov 2004 11:33:42 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan Uphoff References: <4191062A.6090009@elischer.org> <1100024464.29384.30.camel@palm.tree.com> In-Reply-To: <1100024464.29384.30.camel@palm.tree.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org 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:32:53 -0000 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