Re: Page replacement algorithm in buffer cache

On Mon, Apr 1, 2013 at 9:28 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> That is one of multiple issues.  Contention on the BufFreelistLock is
>> another one.  I agree that usage_count maintenance is unlikely to become a
>> bottleneck unless one or both of those is fixed first (and maybe not even
>> then)
>
> usage_count manipulation is not a bottleneck but that is irrelevant.
> It can be affected by other page contention which can lead to priority
> inversion.  I don't be believe there is any reasonable argument that
> sitting and spinning while holding the BufFreelistLock is a good idea.

Hmm.  I'm not sure who if anyone I'm agreeing or disagreeing with, but
I think a big part of the reason why BufFreelistLock contention is
such a big problem is that we do other operations that involve atomics
while we're holding that lock.  You can have contention on a lock even
if you just take it, do some stuff, and release it.  But the longer
you hold the lock for, the less concurrency you need to have in order
to get a contention problem.  And atomics take a LOT longer to execute
than regular instructions - so it seems to me that usage_count
manipulation is relevant not so much because we get contention on the
buffer spinlocks as because it means we're sitting there serially
taking and releasing locks while sitting on BufFreelistLock.

In fact, BufFreelistLock is really misnamed, because for the most
part, the "free list" as we implement is going to be empty.  What the
BufFreelistLock is really doing is serializing the process of scanning
for a free buffer.  I think THAT is the problem.  If we could arrange
things so as to hold BufFreelistLock only for the amount of time
needed to remove a buffer from a freelist ... we'd probably buy
ourselves quite a bit.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company