Date: Tue, 09 Nov 2004 13:40:32 -0500 From: Stephan Uphoff <ups@tree.com> To: Scott Long <scottl@freebsd.org> Cc: Julian Elischer <julian@elischer.org> Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <1100025632.29384.54.camel@palm.tree.com> In-Reply-To: <41910D86.3080605@freebsd.org> References: <Pine.NEB.3.96L.1041109103037.73102S-100000@fledge.watson.org> <1100024464.29384.30.camel@palm.tree.com> <41910D86.3080605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2004-11-09 at 13:33, 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()? > > =-) > > Scott Caugh, caugh ... yes that would be a fine name .... caugh, caugh ;-) Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1100025632.29384.54.camel>