On Fri, Dec 14, 2012 at 9:33 AM, Mikko Tiihonen
<mikko.tiihonen@nitorcreations.com> wrote:
> On 12/13/2012 12:19 AM, Peter Geoghegan wrote:
>>
>> On 12 December 2012 22:11, Mikko Tiihonen
>> <mikko.tiihonen@nitorcreations.com> wrote:
>>>
>>> noticed a "XXX: It might be worth considering using an atomic
>>> fetch-and-add
>>> instruction here, on architectures where that is supported." in lock.c
>>>
>>> Here is my first try at using it.
>>
>>
>> That's interesting, but I have to wonder if there is any evidence that
>> this *is* actually helpful to performance.
>
>
> One of my open questions listed in the original email was request for help
> on
> creating a test case that exercise the code path enough so that it any
> improvements can be measured.
>
> But apart from performance I think there are two other aspects to consider:
> 1) Code clarity: I think the lock.c code is easier to understand after the
> patch
> 2) Future possibilities: having the atomic_inc/dec generally available
> allows
> other performance critical parts of postgres take advantage of them in
> the
> future
This was actually attempted a little while back; a spinlock was
replaced with a few atomic increment and decrement calls for managing
the refcount and other things on the freelist. It helped or hurt
depending on contention but the net effect was negative. On
reflection I think that was because that the assembly 'lock'
instructions are really expensive relative to the others: so it's not
safe to assume that say 2-3 gcc primitive increment calls are cheaper
that a spinlock.
merlin