Re: Page replacement algorithm in buffer cache

On Wed, Apr 3, 2013 at 3:00 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> The main hesitation I've had about actually implementing such a scheme
> is that I find it a bit unappealing to have a background process
> dedicated to just this. But maybe it could be combined with some of
> the other ideas presented here. Perhaps we should have one process
> that scans the buffer arena and populates the freelists; as a side
> effect, if it runs across a dirty buffer, it kicks it over to the
> process described in the previous paragraph (which could still, also,
> absorb requests from other backends using buffer access strategies).
> Then we'd end up with nothing that looks exactly like the background
> writer we have now, but maybe no one would miss it.
>

I think the general pattern of development has led in the opposite
direction. Every time there's been one daemon responsible for two things
it's ended up causing contorted code and difficult to tune behaviours and
we've ended up splitting the two.

In particular in this case it seems like an especially poor choice. In the
time one buffer write might take the entire freelist might empty out. I
could easily imagine this happening *every* time a write I/O happens. It
seems more likely that you'll need multiple processes running the buffer
cleaning to keep up with a decent I/O subsystem.

I'm still skeptical about the idea of a "freelist". That just seems like a
terrible point of contention. However perhaps that's because I'm picturing
an LRU linked list. Perhaps the right thing is to maintain a pool of
buffers in some less contention-prone data structure which lets each
backend pick buffers out more or less independently of the others.

--
greg