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.
- Heikki
