Date: Tue, 09 Nov 2004 10:39:50 -0800 From: Julian Elischer <julian@elischer.org> To: Scott Long <scottl@freebsd.org> Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <41910EF6.8030407@elischer.org> In-Reply-To: <41910D86.3080605@freebsd.org> References: <Pine.NEB.3.96L.1041109103037.73102S-100000@fledge.watson.org> <4191062A.6090009@elischer.org> <1100024464.29384.30.camel@palm.tree.com> <41910D86.3080605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41910EF6.8030407>