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

On 06/10/2015 10:20 AM, Tom Lane wrote:
> Jan Wieck <jan@wi3ck.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