Re: Page replacement algorithm in buffer cache

> I don't be believe there is any reasonable argument that
> sitting and spinning while holding the BufFreelistLock is a good idea.

I completely agree. The idea of spinning for a lock while already
inside a lock seems like a source of a hit to performance.

Regards,

Atri

--
Regards,

Atri
l'apprenant

On Mon, Apr 1, 2013 at 6:58 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Sun, Mar 31, 2013 at 1:27 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> On Friday, March 22, 2013, Ants Aasma wrote:
>>>
>>> On Fri, Mar 22, 2013 at 10:22 PM, Merlin Moncure <mmoncure(at)gmail(dot)com>
>>> wrote:
>>> > well if you do a non-locking test first you could at least avoid some
>>> > cases (and, if you get the answer wrong, so what?) by jumping to the
>>> > next buffer immediately. if the non locking test comes good, only
>>> > then do you do a hardware TAS.
>>> >
>>> > you could in fact go further and dispense with all locking in front of
>>> > usage_count, on the premise that it's only advisory and not a real
>>> > refcount. so you only then lock if/when it's time to select a
>>> > candidate buffer, and only then when you did a non locking test first.
>>> > this would of course require some amusing adjustments to various
>>> > logical checks (usage_count <= 0, heh).
>>>
>>> Moreover, if the buffer happens to miss a decrement due to a data
>>> race, there's a good chance that the buffer is heavily used and
>>> wouldn't need to be evicted soon anyway. (if you arrange it to be a
>>> read-test-inc/dec-store operation then you will never go out of
>>> bounds) However, clocksweep and usage_count maintenance is not what is
>>> causing contention because that workload is distributed. The issue is
>>> pinning and unpinning.
>>
>>
>> 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.
>
> merlin

--
Regards,

Atri
l'apprenant