> Hi,
>
> On Tue, 13 Jul 1999 20:31:48 +0200, Jamie Lokier
> <lkd@tantalophile.demon.co.uk> said:
>
> > This is done already and automatically -- it's called readahead.
> > The kernel detects when you're reading sequentially and then
> > reads ahead.
>
> > We don't do it on mmaped areas yet though.
>
> In 2.2, we do --- sort of. We "readaround", instead --- we page in an
> entire contiguuous 64k-long, 64k-aligned chunk of the file by default
> (less on low-memory machines).
Looks like clusters of pages to me, but should be as good as readaround,
if readaround means read-behind-and-ahead in one chunk. It is also
probably simpler to implement.
> In conjunction with the disk track buffer, this has the effect of
> readahead if you are accessing a mmaped file sequentially in memory ---
> on 2.2, programs which use mmap (such as grep) will happily run at disk
> speed now. The readaround algorithm has the advantage over readahead
> that it also works very well when randomly paging in executable files
> (this is why netscape loads 2 to 3 times faster on 2.2 than on 2.0 on my
> machines).
I donnot follow you here. I understand that we read 64 K at a time, and
not that we queue an IO ahead, so we should still have the latency of the
data going from the disk-cache (hopefully) to memory. But as you know
modern disks have large cache, perform large prefetching, and buses are
very fast. In such a situation, queuing IO ahead is not as interesting as
it used to be in the past.
By the way, I do think that clustering or read-around was the right thing
to implement for page IO.
> --Stephen
Gérard.
-
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/