Re: Spinlocks, yet again: analysis and proposed patches

I wrote:
> We could ameliorate this if there were a way to acquire ownership of the
> cache line without necessarily winning the spinlock.  I'm imagining
> that we insert a "dummy" locked instruction just ahead of the xchgb,
> which touches the spinlock in such a way as to not change its state.

I tried this, using this tas code:

static __inline__ int
tas(volatile slock_t *lock)
{
	register slock_t _res = 1;
	register slock_t _dummy = 0;

	/* Use a locking test before trying to take the spinlock */
	/* xchg implies a LOCK prefix, so no need to say LOCK for it */
	__asm__ __volatile__(
		"	lock			\n"
		"	xaddb	%2,%1	\n"
		"	xchgb	%0,%1	\n"
:		"+q"(_res), "+m"(*lock), "+q"(_dummy)
:
:		"memory", "cc");
	return (int) _res;
}

At least on Opteron, it's a loser.  The previous best results (with
slock-no-cmpb and spin-delay patches) were
	1 31s	2 42s	4 51s	8 100s
and with this instead of slock-no-cmpb,
	1 33s	2 45s	4 55s	8 104s

The xadd may indeed be helping in terms of protecting the xchg from
end-of-timeslice --- the rate of select() delays is really tiny, one
every few seconds, which is better than I saw before.  But the extra
cost of the extra locked operation isn't getting repaid overall.
Feel free to try it on other hardware, but it doesn't look promising.

BTW, I also determined that on that 4-way Opteron box, the integer
modulo idea doesn't make any difference --- that is, spin-delay and
what Michael called spin-delay-2 are the same speed.  I think I had
tried the modulo before adding the variable spin delay, and it did
help in that configuration; but most likely, it was just helping by
stretching out the amount of time spent looping before entering the
kernel.  So we can drop that idea too.

			regards, tom lane