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

On 06/10/2015 11:06 AM, Nils Goroll wrote:
> On 10/06/15 16:18, Jan Wieck wrote:
>>
>> I have played with test code that isolates a stripped down version of s_lock()
>> and uses it with multiple threads. I then implemented multiple different
>> versions of that s_lock(). The results with 200 concurrent threads are that
>> using a __sync_val_compare_and_swap() to acquire the lock and then falling back
>> to a futex() is limited to about 500,000 locks/second. Spinning for 10 times and
>> then doing a usleep(1000) (one millisecond) gives me 25 million locks/second.
>>
>> Note that the __sync_val_compare_and_swap() GCC built in seems identical in
>> performance with the assembler xchgb operation used by PostgreSQL today on x84_64.
>
> These numbers don't work for me. Do IUC that you are not holding the lock for
> any reasonable time? If yes, the test case is invalid (the uncontended case is
> never relevant). If No, the numbers don't match up - if you held one lock for
> 1ms, you'd not get more than 1000 locks/s anyway. If you had 200 locks, you'd
> get 200.000 locks/s.
>
> Can you please explain what the message is you are trying to get across?

The test case is that 200 threads are running in a tight loop like this:

for (...)
{    s_lock();    // do something with a global variable    s_unlock();
}

That is the most contended case I can think of, yet the short and 
predictable code while holding the lock is the intended use case for a 
spinlock.

The code in s_lock() is what is doing multiple CAS attempts, then sleep. 
The code is never holding the lock for 1ms. Sorry if that wasn't clear.


Regards, Jan


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