Re: Page cache ageing: yae or nae?

[Rik van Riel <H.H.vanRiel@phys.uu.nl>]

On Mon, 27 Jul 1998, Stephen C. Tweedie wrote:

> Could you let me know just what benchmarks you were running when you
> added the first page ageing code to see a speedup?  I think we need to

It's not really a benchmark; it's just that mp3s or
quicktimes (played from disk instead of ram) run
smoothly with page aging and skip without.

> look carefully at the properties of the ageing scheme and the simple
> clock algorithm we had before to see where the best compromise is.  It

The clock algorithm will throw out the not-yet-used page we
just read-ahead (and which will be needed immediately after
clearing -- cf. Murphy).

An aging (or better, LRU) algorithm will only throw out the
read-ahead page if:
- we don't use it in a larger time
- we have used it and don't use it any more

One of the ideas behind this is that swap I/O is clustered
and often cheaper than filesystem I/O (both are the case on
my system, which is tuned for this).

On systems with a single spindle and the swap partition
_far_ away, both assumptions will obviously break.

Since both types of systems can be found rather often, a
dynamic scheme would probably be best; maybe even a 'cost'
factor on mounting/swapon...

> may be that we can get away with something simple like just reducing
> the initial page age for the page cache, but I'd like to make sure
> that the readahead problems you alluded to are not brought back by any
> other changes we make to the mechanism.

The problem is with balancing, not with balancing memory usage,
but with balancing I/O cost.

I think we should think up a mechanism that both preserves the
readahead performance and balances I/O; memory balancing is a
tertiary issue here...

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org