I find it hard to believe that they are not doing the job - the
performance would really suck if this were the case. Do you happen to know
exactly what it was that Larry was counting? When I have looked at things
from the scsi end of things, it seemed to be working correctly.
Are you testing reads, writes, or both?
Both (see the original numbers I provided). I haven't yet had a chance to look
into this in sufficient detail (nor your SCSI reset changes, alas), and I
probably won't for the next couple of weeks, as another unrelated project has
higher priority.
When I can get back to this seriously, I plan to start from scratch looking at
the I/O performance starting with an updated and modified copy of the
scsi_ioctl.c benchmarking hack you did a while back, and trace the SCSI
operations in my BusLogic driver to see precisely what sequence of operations
is being requested for these sustained I/O tests.
My guess is that there is some overhead in setting up and
working with the additional buffer headers that you have with 1K blocksizes.
That may well be the case, but 486DX4-100's and Pentium-100's ought to be fast
enough to handle this while keeping a single SCSI drive saturated. I think the
performance limitation could well be due to latency issues making it impossible
to keep the drive busy.
I'll keep people up to date with what I uncover when I get back to this. I
also want to investigate the MD patches.
I think the buffer cache code is due for a complete rewrite, but it
gets a bit tricky as there are lots of considerations.
This wouldn't surprise me a bit.
Leonard