Re: [PATCH] Optimize libc_lock_lock for MIPS XLP.

[Chris Metcalf <cmetcalf at tilera dot com>]

On 6/27/2012 5:45 PM, Maxim Kuvyrkov wrote:
> On 15/06/2012, at 2:49 PM, Maxim Kuvyrkov wrote:
>
>> > On 15/06/2012, at 2:44 PM, Chris Metcalf wrote:
>> > 
>>> >> On 6/14/2012 9:20 PM, Maxim Kuvyrkov wrote:
>> > ...
>>>> >>> As I read it, in case of a contended lock __lll_lock_wait will reset the value of the lock to "2" before calling lll_futex_wait().  I agree that there is a timing window in which the other threads will see a value of the lock greater than "2", but the value will not get as high as hundreds or billions as it will be constantly reset to "2" in atomic_exchange in lll_lock_wait().
>>>> >>> 
>>>> >>> I do not see how threads will get into a busywait state, though.  Would you please elaborate on that?
>>> >> 
>>> >> You are correct.  I was thinking the that the while loop had a cmpxchg, but
>>> >> since it's just a straight-up exchange, the flow will be something like:
>>> >> 
>>> >> - Fail to initially call lll_futex_wait() if the lock is contended
>>> >> - Fall through to while loop
>>> >> - Spin as long as the lock is contended enough that *futex > 2
>>> >> - Enter futex_wait
>>> >> 
>>> >> So a little busy under high contention, but probably settles out reasonably
>>> >> well.
>> > 
> Attached is an improved patch that also optimizes __libc_lock_trylock using XLP's atomic instructions.
>
> The patch also removes unnecessary indirection step represented by new macros lll_add_lock, which is then used to define __libc_lock_lock, and defines __libc_lock_lock and __libc_lock_trylock directly in lowlevellock.h .  This makes changes outside of ports/ trivial.
>
> Tested on MIPS XLP with no regressions.  OK to apply for 2.17?

It looks OK to me.  I would want someone else to sign off on it before
applying to 2.17.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com