On Monday 07 October 2002 21:24, Linus Torvalds wrote:
> On Mon, 7 Oct 2002, Daniel Phillips wrote:
> >
> > Devices have a few MB of readahead cache, the kernel can have thousands of
> > times as much.
>
> I don't think that is in the least realistic.
>
> There's _no_ way that the krenel could do physical readahead for more than
> a few tens or hundreds of kB
If that's a bet, I'll take you up on it.
> - the latency impact would just be too much
> to handle, and the VM impact is not likely insignificant either.
I did say difficult. It really is, but there are big gains to be had.
This is easy to verify: say you have 100 MB of kernel source stored in, say,
50 different clumps on disk. Complete with seeks, a perfectly prescient
readahead algorithm can read that into memory in about 5 seconds, even with
my lame scsi raid controller[1]. So two of those needs 10 seconds, and I
can diff those two trees in 2 seconds, in cache. In practice it takes 90
seconds, so there is obviously a lot of room for improvement.
Note that if the disks really were capable of handling the readahead
themselves they would already give me the 12 second result, not the 90
seconds. They simply can't, because they haven't got enough cache.
[1] If the controller wasn't lame it would read the 100 MB in less than a
second, with its (peak) total of 200 MB/s media bandwith, less 20% worth
of parity blocks.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:01:00 EST