From owner-cvs-src@FreeBSD.ORG Tue Nov 9 18:39:54 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 A97EA16A541; Tue, 9 Nov 2004 18:39:51 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1301343D31; Tue, 9 Nov 2004 18:39:51 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id E959E7A423; Tue, 9 Nov 2004 10:39:50 -0800 (PST) Message-ID: <41910EF6.8030407@elischer.org> Date: Tue, 09 Nov 2004 10:39:50 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Scott Long References: <4191062A.6090009@elischer.org> <1100024464.29384.30.camel@palm.tree.com> <41910D86.3080605@freebsd.org> In-Reply-To: <41910D86.3080605@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Stephan Uphoff cc: Robert Watson 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: Tue, 09 Nov 2004 18:39:54 -0000 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()? > > =-) yes.. maybe we need to re-imp[lelemnt it. in a sort-of "all-or-nothing" way splhi() and splx() and nothing between. > > > Scott