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