Re: ReadRecentBuffer() doesn't scale well

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: ReadRecentBuffer() doesn't scale well
Дата
Msg-id 20230627170710.7inv4nlsqay6q56e@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: ReadRecentBuffer() doesn't scale well  (Ants Aasma <ants@cybertec.at>)
Список pgsql-hackers
Hi,

On 2023-06-27 19:04:31 +0300, Ants Aasma wrote:
> On Tue, 27 Jun 2023 at 18:40, Andres Freund <andres@anarazel.de> wrote:
> > On 2023-06-27 14:49:48 +0300, Ants Aasma wrote:
> > > If you want to experiment, here is a rebased version of something I
> > > hacked up a couple of years back on the way to Fosdem Pgday. I didn't
> > > pursue it further because I didn't have a use case where it showed a
> > > significant difference.
> >
> > Thanks for posting!
> >
> > Based on past experiments, anything that requires an atomic op during spinlock
> > release on x86 will be painful :/. I'm not sure there's a realistic way to
> > avoid that with futexes though :(.
> 
> Do you happen to know if a plain xchg instruction counts as an atomic
> for this? I haven't done atomics stuff in a while, so I might be
> missing something, but at first glance I think using a plain xchg
> would be enough for the releasing side.

It is automatically an atomic op when referencing memory:

Intel SDM 9.1.2.1 Automatic Locking:
"The operations on which the processor automatically follows the LOCK semantics are as follows:
• When executing an XCHG instruction that references memory.
...
"

Theoretically cmpxchg can be used in a non-atomic fashion. I'm not sure that
can be done correctly though, if you want to also store a separate value for
the futex. This stuff is hard to think though :)

Greetings,

Andres Freund



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

Предыдущее
От: Roberto Mello
Дата:
Сообщение: Re: PostgreSQL 16 Beta 2 release announcement draft
Следующее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: PostgreSQL 16 Beta 2 release announcement draft