Re: Page replacement algorithm in buffer cache

On Tue, Mar 26, 2013 at 11:40 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Fri, Mar 22, 2013 at 04:16:18PM -0400, Tom Lane wrote:
>> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> > I think there is some very low hanging optimization fruit in the clock
>> > sweep loop. first and foremost, I see no good reason why when
>> > scanning pages we have to spin and wait on a buffer in order to
>> > pedantically adjust usage_count. some simple refactoring there could
>> > set it up so that a simple TAS (or even a TTAS with the first test in
>> > front of the cache line lock as we done automatically in x86 IIRC)
>> > could guard the buffer and, in the event of any lock detected, simply
>> > move on to the next candidate without messing around with that buffer
>> > at all. This could construed as a 'trylock' variant of a spinlock
>> > and might help out with cases where an especially hot buffer is
>> > locking up the sweep. This is exploiting the fact that from
>> > StrategyGetBuffer we don't need a *particular* buffer, just *a*
>> > buffer.
>>
>> Hm. You could argue in fact that if there's contention for the buffer
>> header, that's proof that it's busy and shouldn't have its usage count
>> decremented. So this seems okay from a logical standpoint.
>>
>> However, I'm not real sure that it's possible to do a conditional
>> spinlock acquire that doesn't create just as much hardware-level
>> contention as a full acquire (ie, TAS is about as bad whether it
>> gets the lock or not). So the actual benefit is a bit less clear.
>
> Could we view the usage count, and if it is 5, and if there is someone
> holding the lock, we just ignore the buffer and move on to the next
> buffer? Seems that could be done with no locking.

The idea is that if someone is "holding the lock" to completely ignore
the buffer regardless of usage. Quotes there because we test the lock
without cacheline lock. Now if the buffer is apparently unlocked but
returns locked once you *do* acquire cache line lock in anticipation
of refcounting, again immediately bail and go to next buffer.

I see no reason whatsoever to have buffer allocator spin and wait on a
blocked buffer. This is like jumping onto a merry-go-round being spun
by sadistic teenagers.

merlin