Re: ReadRecentBuffer() doesn't scale well

On Tue, 27 Jun 2023 at 07:09, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2023-06-27 15:33:57 +1200, Thomas Munro wrote:
> > On Tue, Jun 27, 2023 at 2:05 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > Unfortunately it scaled way worse at first. This is not an inherent issue, but
> > > due to an implementation choice in ReadRecentBuffer(). Whereas the normal
> > > BufferAlloc() path uses PinBuffer(), ReadRecentBuffer() first does
> > > LockBufHdr(), checks if the buffer ID is the same and then uses
> > > PinBuffer_Locked().
> > >
> > > The problem with that is that PinBuffer() takes care to not hold the buffer
> > > header spinlock, it uses compare_exchange to atomically acquire the pin, while
> > > guaranteing nobody holds the lock. When holding the buffer header spinlock,
> > > there obviously is the risk of being scheduled out (or even just not have
> > > exclusive access to the cacheline).
> >
> > Yeah. Aside from inherent nastiness of user-space spinlocks
>
> I've been wondering about making our backoff path use futexes, after some
> adaptive spinning.

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.

--
Ants