Re: readahead/behind algorithm

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

On Mon, 7 Dec 1998, Stephen C. Tweedie wrote:
> On Mon, 7 Dec 1998 21:17:56 +0100 (CET), Rik van Riel
> <H.H.vanRiel@phys.uu.nl> said:
> 
> > I've thought a bit about what the 'ideal' readahead/behind
> > algorithm would be and reached the following conclusion.
> 
> > 1. we test the presence of pages in the proximity of the
> >    faulting page (31 behind, 32 ahead) building a map of
> >    64 pages.
> 
> It will only be useful to start getting complex here if we take more
> care about maintaining the logical contiguity of pages when we swap
> them.

We will need to test 2 proximities, the one in the process'
address space (of which I was talking here) and the one in
swap space. We only read those virtual addresses that can
be scooped off of swap in one sweep and those that can be
properly clustered.

The rest we put in a new swap bitmap (actually two bitmaps,
which get cleaned&written alternately so we can forget old
requests without forgetting new ones) and we read those pages
only when they become clusterable due to other I/O requests
happening near them or when the process faults on them.

> If swap gets fragmented, then doing this sort of readahead will just
> use up bandwidth without giving any measurable performance gains. 
> It would be better thinking along those lines right now, I suspect. 

At the moment, yes. To do the stuff I wrote about we'd need to
clone about half the code from vmscan.c and pass the faulting
address to swap_in() as an extra parameter.

We probably only want this (expensive!) swapin code on machines
than run multiple large simulations and have loads of memory
but even more swap. It will be a lot of fun to write though :)

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| 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