On 06/10/2015 10:59 AM, Robert Haas wrote:
> On Wed, Jun 10, 2015 at 10:20 AM, Tom Lane <tgl@sss.pgh.pa.us> 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 code seems to have been written with the idea that we should
> converge to MAX_SPINS_PER_DELAY if spinning *ever* works. The way
> that's implemented is that, if we get a spinlock without having to
> delay, we add 100 to spins_per_delay, but if we have to delay at least
> once (potentially hundreds of times), then we subtract 1.
> spins_per_delay will be >900 most of the time even if only 1% of the
> lock acquisitions manage to get the lock without delaying.
And note that spins_per_delay is global. Getting ANY lock without delay
adds 100, regardless of that being a high or low contented one. Your
process only needs to hit one low contention slock every 100 calls to
securely peg this value >=900.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
