On Sun, Mar 31, 2013 at 1:27 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Friday, March 22, 2013, Ants Aasma wrote:
>>
>> On Fri, Mar 22, 2013 at 10:22 PM, Merlin Moncure <mmoncure@gmail.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
