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