* Kris Kennaway <[EMAIL PROTECTED]> [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 _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
