Date: Tue, 16 Oct 2007 15:21:06 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Kris Kennaway <kris@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Jason Evans <jasone@freebsd.org>, cvs-all@FreeBSD.org, David Xu <davidxu@FreeBSD.org> Subject: Re: cvs commit: src/lib/libthr/thread thr_pspinlock.c Message-ID: <20071016222106.GF31826@elvis.mu.org> In-Reply-To: <47150841.2080306@FreeBSD.org> References: <200710160736.l9G7a3oI087966@repoman.freebsd.org> <471480AB.7090500@FreeBSD.org> <4714F750.9010804@freebsd.org> <47150841.2080306@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Kris Kennaway <kris@FreeBSD.org> [071016 11:51] wrote: > Jason Evans wrote: > >Kris Kennaway wrote: > >>David Xu wrote: > >>> FreeBSD src repository > >>> > >>> Modified files: > >>> lib/libthr/thread thr_pspinlock.c Log: > >>> Reverse the logic of UP and SMP. > >>> Submitted by: jasone > >>> Revision Changes Path > >>> 1.6 +1 -1 src/lib/libthr/thread/thr_pspinlock.c > >> > >>Are there any common applications that use this? > > > >It's worth mentioning that this change, although correct, does not make > >a measurable performance difference for the tests I was running when I > >found the bug. It is possible that making the spinlocks adaptive would > >help, but I didn't look into this. > > > >(I was working on malloc performance enhancements that have turned out > >very nicely, but in the end I had to switch to hand-rolled "spin" > >mutexes that eventually convert to blocking, in order to avoid the > >possibility of unrecoverable priority inversion.) > > BTW I am looking at adding a non-portable (sort of) pthread mutex type > that spins for a while when the lock is held, before blocking. This is > sometimes good for performance when the pthread mutex is highly > contended but held for short periods of time, and in fact Linux has such > a mutex that is used by mysql with performance benefits. > > The real fix would be to make them adaptive in the same way as kernel > mutexes (spin as long as the lock holder is running), but there is > currently no easy way for userland to peer into the kernel to check the > other thread's state. Soon.... :D -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071016222106.GF31826>