Re: Spinlocks, yet again: analysis and proposed patches

I thought I'd throw SPARC into the equation (SPARC IIIi, in a dual SunFire
v250):

vanilla HEAD from ~1 week ago:

bash-3.00$ for i in 1 2 4; do time ./nrun.sh $i; done

real 1m49.037s
user 0m0.008s
sys 0m0.016s

real 2m3.482s
user 0m0.014s
sys 0m0.026s

real 3m54.215s
user 0m0.028s
sys 0m0.046s

With the spin-delay patch:

real 1m50.791s
user 0m0.008s
sys 0m0.016s

real 2m0.553s
user 0m0.015s
sys 0m0.026s

real 3m58.185s
user 0m0.027s
sys 0m0.048s

Padding the LWLock to 64 bytes:

bash-3.00$ for i in 1 2 4; do time ./nrun.sh $i; done

real 1m49.594s
user 0m0.008s
sys 0m0.016s

real 1m59.141s
user 0m0.015s
sys 0m0.026s

real 3m56.236s
user 0m0.027s
sys 0m0.047s

Padded to 128 bytes (I'm not sure about the cache line size):

real 1m50.498s
user 0m0.008s
sys 0m0.016s

real 2m0.169s
user 0m0.015s
sys 0m0.026s

real 3m56.891s
user 0m0.027s
sys 0m0.048s

----

These details seem suspicious to me when compared to those we're seeing on
x86 platforms. The reason is that padding the LWLock out to 64 or 128
bytes makes no difference (maybe the cache line is bigger?). The good
thing is, the difference between 1 and 2 instances of the test is small --
precisely what we want.

Thanks,

Gavin