Actually, the patch in 1.3.85 is not the same patch that was on the
kernel mailing list earlier. That patch probably improved performance
more, but I didn't like how it was done.
The 1.3.85 read-ahead changes are more of a update to how we do it than a
performance improvement. It should improve performance slightly, but it's
really a case of building the foundations for future improvements rather
than being a huge improvement in itself.
(The asynchronous read-ahead that the kernel mailing list patch added is
not really done in 1.3.85 - the code is there, but it doesn't really do
any real async read-ahead yet in normal circumstances).
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> Lnx1380 100 3221 60.4 2973 19.9 1150 13.9 2300 44.1 2844 12.9 45.9 2.3
> Lnx1384 180 2395 43.4 2714 17.2 1339 16.7 2519 47.2 3253 14.6 69.2 2.9
> Lnx1385 180 2520 44.9 3204 19.8 1258 16.1 2721 56.6 3220 16.0 70.1 3.0
>
> This machine is a 266 MHz Alpha-XL with integrated NCR 53C810, and
> Seagate ST31230N SCSI-disk. At the last two tests the system had
> 128 MB memory, while with the first one there was propably 32 MB memory.
>
> My point, either we are limited by the disk, or perhaps the NCR-driver
> is not as good as it could be... The read-ahead does not help noticeably.
I suspect it's pretty close to be limited by the disk. Getting 3.2MB/s
sustained is very reasonable, although it's hard to tell (I have no idea
what the ST31230N is supposed to be able to deliver).
I don't think it's much of a driver issue: bonnie really tests the other
things more (tagged queueing etc features should not matter for bonnie,
we should be doing just "simple" requests most of the time). The queuing
code and buffer cache shows up much more, assuming the driver is at least
reasonable.
Linus