[lkml]   [1999]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] - Some notions that I would like comments on

On Wed, 14 Jul 1999, Stephen C. Tweedie wrote:

> Hi,
> On Tue, 13 Jul 1999 20:31:48 +0200, Jamie Lokier
> <> 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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.089 / U:0.148 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site