On 9 July 2018 at 14:49, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 03/04/18 19:20, Andres Freund wrote:
>>
>> On 2018-04-03 09:56:24 -0400, Tom Lane wrote:
>>>
>>> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>>>>
>>>> But let's go back to why we're considering this. The idea was to
>>>> optimize this block:
>>>> ...
>>>> One trick that we could do is to replace that with a 128-bit atomic
>>>> compare-and-swap instruction. Modern 64-bit Intel systems have that,
>>>> it's called CMPXCHG16B. Don't know about other architectures. An atomic
>>>> fetch-and-add, as envisioned in the comment above, would presumably be
>>>> better, but I suspect that a compare-and-swap would be good enough to
>>>> move the bottleneck elsewhere again.
>>>
>>>
>>> +1 for taking a look at that. A bit of experimentation shows that
>>> recent gcc and clang can generate that instruction using
>>> __sync_bool_compare_and_swap or __sync_val_compare_and_swap
>>> on an __int128 value.
>>
>>
>> The problem will presumably be that early opteron AMD64s lacked that
>> instruction. I'm not sure which distributions still target them (windows
>> dropped support a few years ago), but we should make sure that neither
>> the necessary dispatch code isn't going to add so much overhead it's
>> eating into our margin, nor that the generated code SIGILLs on such
>> platforms.
>
>
> Yeah.
>
> I'll mark this as "returned with feedback" in the commitfest. The way
> forward is to test if we can get the same performance benefit from switching
> to CMPXCHG16B, and keep the WAL format unchanged. If not, then we can
> continue discussing the WAL format and the tradeoffs with xl_prev, but let's
> take the easy way out if we can.
Agreed. Were you working on this? Or was anybody else?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
