On Wed, 14 Jul 1999 19:52:56 +0200 (MET DST), Gerard Roudier
<groudier@club-internet.fr> said:
>> 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.
They are both just as easy to implement, but the clustered readaround
means that hits to adjacent clusters result in pulling the two entire
clusters, with no overlap and no missed blocks between the pageins. It
reduces the seek count for paging binaties.
>> In conjunction with the disk track buffer, this has the effect of
>> readahead if you are accessing a mmaped file sequentially in memory
> 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.
Exactly, but for sequential access you are typically measuring
bandwidth, not latency, and the disk cache hides the latency enough to
let us keep the disk streaming at media bandwidth. There is definitely
a latency hit which we could avoid if we pre-submitted the next cluster
read.
> 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.
Yes, absolutely.
--Stephen
-
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/