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 по дате отправления: