On Wed, May 23, 2012 at 8:36 AM, Amit Kapila <amit.kapila@huawei.com> wrote:
>>>And besides
>>>if the decrements are decoupled from the allocation requests it's no
>>>longer obvious that the algorithm is even an approximation of LRU.
>
> I was trying to highlight that we can do the clocksweep in bgwriter and keep
> the backends logic as it is currently.
> The core idea is that it will reduce the work of backends and chances of
> them to get the free buffer early than currently will be more.
Do we have any evidence that this is actually a problem which needs to
be solved? I've seen plenty of evidence that contention for the lock
can be a problem, but no evidence that the amount of work done under
the lock, once it is obtained, is a problem.
> Some of the other ideas about it which I have discussed are
> 1. moving clean buffers to freelist when any found by bgwriter or
> checkpoint. This is to get the buffers early by backends without going into
> clock sweep algorithm.
You would need to lock once to put the buffer on, and again to take it
off. That increases the traffic through a contended lock, rather than
decreasing it. So unless this is coupled with reducing the lock
strength, I don't see how it can win.
>
> 2. having multiple lists of hot and cold buffers and backends will find the
> buffers in following order if the required buffer is not already there
> a. freelist
> b. cold list
> c. hot list
>
> 3. try to experiment with different values of usage count under heavy load
> scenarios and check does it make any difference.
One thing I wanted to play with is having newly read buffers get a
usage count of 0 rather than 1. The problem is that there is no way
to test it in enough different situations to convince people it would
be a general improvement.
Cheers,
Jeff