Skip site navigation (1)Skip section navigation (2)
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>