Date: Wed, 17 Oct 2007 16:51:31 +0800 From: David Xu <davidxu@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 Subject: Re: cvs commit: src/lib/libthr/thread thr_pspinlock.c Message-ID: <4715CD13.20205@freebsd.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 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. > > Kris > I have a patch to adaptively spin in userland, kernel is not involved. http://people.freebsd.org/~davidxu/patch/libthr_spin.patch I have not seen visible performance improvement in some tests, unlike kernel code, many user application code do not care parallel performance, they only care exclusive accessing to a resource, you can call them badly written code, so spinning is not always useful. However, with this patch, Sun's mutex ping-pong program's performance is massively improved, try it. Regards, David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4715CD13.20205>