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
>