From: pcg@decb.aber.ac.uk (Piercarlo Antonio Grandi) Subject: Re: SCSI Performance (Yet Again) Date: Thu, 26 Aug 1993 16:21:44 GMT
On Mon, 23 Aug 1993 01:34:12 GMT, Remco Treffkorn (root@hip-hop.suvl.ca.us) wrote:
: Actually one would want to have an idea of how good each of these
: components is *in isolation*;
:
: 1) the generic SCSI code
: 2) the HA specific SCSI code
: 3) the disk SCSI code
: 4) the filesystem code
: 5) the cache handling code.
Do you volunteer to find out ? ;-)
I have been trying, informally -- I am really keen on IO performance.
But it's not so easy -- one dos not have the right hooks in the
kernel/device drivers.
: Also, it is rather useful to observe not only how long (elapsed) the
: operations take, but also the system CPU time taken.
Yes and no and yes. I think that goes hand in hand. It is like saying
you get wet when it rains.
It is more interesting than you think. In theory elapsed tiem should be much
larger than CPU time, unless the kernel/drivers/cache/filesystem code are
poorly written and they also take a lot of CPU time, as in SVR4 or Ultrix.
Linux seems, from first impressions, rather leaner than those, and CPU time
not such big worry.
: that the biggest problems are, in order of decreasing
: importance:
: a) the filesystems don't do read/write clustering.
Iozone does sequential reads/writes. Where is the gain?
It makes a lot of difference if the driver can issues a single scatter/gather
command to read/write multiple blocks or not.
: b) advising for expected access patterns should be
: possible/automatic.
Right, but sequential writes do not benefit too much from it.
No, they would benefit *most* from it. Caches, even buffer caches, tend to
use LIFO style policies; sequential is FIFO. Even if read-ahead/write
behind are implemented, advising can tune their lengths.
I tend to agree with your list in part. I still *feel* that with what
there is the performance should be better.
Yes, but I think this is not so much a problem with the kernel/drivers
as with the policies of cache and filesystem.
If I understand you correctly, you are saying the current numbers are as
good as they can be, given the current design. My gut feeling is that this
is not so.
Bah, bah. The numbers I have seen are 'as good as possible'. This is a
bit clouded by the fact that raw disk devices are not available.