Re: s_lock() seems too aggressive for machines with many sockets

On 06/10/2015 10:20 AM, Tom Lane wrote:
> Jan Wieck <jan(at)wi3ck(dot)info> writes:
>> The attached patch demonstrates that less aggressive spinning and (much)
>> more often delaying improves the performance "on this type of machine".
>
> Hm. One thing worth asking is why the code didn't converge to a good
> value of spins_per_delay without help. The value should drop every time
> we had to delay, so under heavy contention it ought to end up small
> anyhow, no? Maybe we just need to alter the feedback loop a bit.
>
> (The comment about uniprocessors vs multiprocessors seems pretty wacko in
> this context, but at least the sign of the feedback term seems correct.)

The feedback loop looks a bit heavy leaning towards increasing the spin
count vs. decreasing it (100 up vs. 1 down). I have test time booked on
the machine for tomorrow and will test that as well.

However, to me it seems that with the usual minimum sleep() interval of
1ms, once we have to delay at all we are already losing. That spinning
10x still outperforms the same code with 1,000 spins per delay by factor
5 tells me that "on this particular box" something is going horribly
wrong once we get over the tipping point in concurrency. As said, I am
not sure what exactly that is yet. At a minimum the probability that
another CPU package is stealing the cache line from the one, holding the
spinlock, is going up. Which cannot possibly be good for performance.
But I would expect that to show a more gradual drop in throughput than
what I see in the pgbench -S example. Kevin had speculated to me that it
may be possible that at that tipping point the kernel starts feeling the
need to relocate the memory page in question to whichever cpu package
makes the most failing requests and thus ends up with a huge round robin
page relocation project. Unfortunately I don't know how to confirm or
disprove that theory.

This is done on CentOS 7 with kernel 3.10 BTW. And no, I am not at
liberty to install a different distribution or switch to another kernel.

Regards, Jan

--
Jan Wieck
Senior Software Engineer
http://slony.info