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