> 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.
My patch was experimental but does the right work.
Yours seems to be good, but is catastrophic with drivers that can queue more
than one command at a time for a device.
I would be better that you let filemap.c unchanged.
> 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.
About 46 words to say what?
> (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).
I agree.
> 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).
Seems to me that the driver is configured to do asynchrounous SCSI
transfers only (About 3.5 MB/sec max).
> 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.
The standard NCR driver for Linux can queue up to 4 commands per lun,
without support of Tagged Queue.
In that situation, command sorting algorithm of the kernel is quite
broken.
We have luck with Bonnie since its sequential accesses does not need to
sort IO requests.
Allowing more than 1 command per lun in a SCSI driver without support of
tagged queue is Silly, since command sorting algorithm of the
kernel is broken for nothing (save perhaps some micro-seconds/command).
This behaviour may have some bad effects on performances with production
systems.
Best Regards, Gerard.