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