Re: Move PinBuffer and UnpinBuffer to atomics

From: Andres Freund <andres(at)anarazel(dot)de>
To: YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Move PinBuffer and UnpinBuffer to atomics
Date: 2015-09-15 16:47:40
Message-ID: 20150915164740.GA2086@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-09-15 19:43:28 +0300, YUriy Zhuravlev wrote:
> On Tuesday 15 September 2015 16:50:44 Andres Freund wrote:
> > No, they can't in a a relevant manner. We hold the buffer header lock.
> I'm sorry, I did not notice of a LockBufHdr.
>
> In this embodiment, your approach seems to be very similar to s_lock. Cycle in
> PinBuffer behaves like s_lock.

> In LockBufHdr:
> if (pg_atomic_compare_exchange_u32(&desc->state, &state, state | BM_LOCKED))
>
> conflict with:
> while (unlikely(state & BM_LOCKED))
> from PinBuffer.
> Thus your patch does not remove the problem of competition for PinBuffer.
> We will try check your patch this week.

That path is only taken if somebody else has already locked the buffer
(e.g. BufferAlloc()). If you have contention in PinBuffer() your
workload will be mostly cache resident and neither PinBuffer() nor
UnpinBuffer() set BM_LOCKED.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anastasia Lubennikova 2015-09-15 16:57:24 Re: [PROPOSAL] Covering + unique indexes.
Previous Message Ildus Kurbangaliev 2015-09-15 16:44:19 Re: [PATCH] Refactoring of LWLock tranches