Date: Tue, 16 Oct 2007 21:18:15 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> 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: <20071016211711.B598@10.0.0.1> 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
On Tue, 16 Oct 2007, 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. One thing that was suggested was to spin for a set number of times in user-space before entering the syscall which could continue to spin as long as the target was running. The initial few spins would catch quite a few cases and avoid the syscall overhead. Then the spin in kernel could last for longer and avoid the switch overhead. Sort of a hybrid approach. Jeff > > Kris >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071016211711.B598>