Re: Changing WAL Header to reduce contention duringReserveXLogInsertLocation()

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Changing WAL Header to reduce contention duringReserveXLogInsertLocation()
Дата
Msg-id 20180403162005.c6sajrm6bu6rfe6q@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Changing WAL Header to reduce contention duringReserveXLogInsertLocation()  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
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.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kapil Sharma
Дата:
Сообщение: Re: Running Installcheck remotely
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Optimize Arm64 crc32c implementation in Postgresql