Re: ReadRecentBuffer() doesn't scale well - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ReadRecentBuffer() doesn't scale well
Date
Msg-id 20230627170710.7inv4nlsqay6q56e@awork3.anarazel.de
Whole thread Raw
In response to Re: ReadRecentBuffer() doesn't scale well  (Ants Aasma <ants@cybertec.at>)
List 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 by date:

Previous
From: Roberto Mello
Date:
Subject: Re: PostgreSQL 16 Beta 2 release announcement draft
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: PostgreSQL 16 Beta 2 release announcement draft