> Does it just use `map 8 implies prefetch 16-31' ?
No. Map 8 _and_ 8 is already present in memory means
prefetch 16-31. If 8 is not present in memory yet we
don't prefetch 16-31.
> If so, what if the application does 1 3 5 7 9 ?
9 should work the same way as 8. In fact, anything >7 should
work. It really doesn't cost us any extra I/O in the case of
sequential stuff since we will have already read in the pages
when we were at 8...
> Or what if the application does `1 567 34 90 9486 8' ?
> Should the last 8 trigger prefetch of 16-31 ?
I don't see how it would hurt. If 8 is still present we're
not short on memory.
To put it more bluntly: on modern (>1997) machines we're never
short on memory or disk throughput speed. Our only _real_ VM
bottleneck is with disk seek time. That is our major enemy and
we need to battle it with every means available to us.
> Using `read' is like giving an implicit `madvise(SEQUENTIAL)'
> since it's rarely used for random (or even stride) access.
> `mmap' has to be more careful.
As I said, seek time is our enemy and sequential reads are
cheap. In fact, all asynchronous reads are cheap since we
don't waste the application's time. If we succeed in doing
more than 50% of all reads asynchronously and just before
the app needs the data, then performance will fly to new
heights even if the disk is thrashing like mad...
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/