> How about cluing in the VM to prefetch with madvise() ? How would this
> effect performance?
>
> It's a kludge.
And it's not needed at all. We can see if the program is
doing sequential reading by simply testing for the presence
of pages in the proximity of the faulting address. If there
are a lot of pages present behind the current address then
we should do read-ahead. With pages in front of us we want
read-behind and with no pages or an 'equal' distribution
we want a little bit of both read-ahead and read-behind...
> - If read() caused prefetching of blocks, the when a page faulted in
> from an mmap() mapping, why wouldn't this cause prefetching?
>
> You have to "prime" the read prefetcher first by asking for a couple
> big chunks via read() first.
And nobody has gotten around to coding the above hinting code
for mmap() and swap_in() yet... This is a 2.3 issue -- have
patience or code it yourself :)
> - When a binary executable image is mmap()ed to be run, wouldn't you want
> to prefetch blocks of code and data -- what would be the difference
> between this and the user mmap()ing in a file?
>
> Sure, but what is your limit to pre-faulting pages in? I tried this
> once and hit this very problem. FreeBSD and some other systems have a
> hard coded limit of the number of pages to do this for as a ceiling, I
> think this is not the answer.
And once again everybody seems to forget about read-behind --
which is very useful for excutables where the calling function
is often located at the bottom of the C file and also at the
bottom of the object file and thus in front of the function it
will call almost immediately -- read-behind would help a lot in
a case like this...
You should probably rest assured by the fact that I (and Stephen?)
will be working on this as soon as Stephen has done his other
important stuff and I've chewed through a proper scheduler for SMP...
You probably won't see the code integrated before 2.3, so don't
hold your breath :)
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/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/