From: root@hip-hop.suvl.ca.us (Remco Treffkorn) Subject: Re: SCSI Performance (Yet Again) Date: Mon, 23 Aug 1993 01:34:12 GMT
pcg@aber.ac.uk (Piercarlo Grandi) writes:
: >>> On Sat, 21 Aug 1993 16:47:58 GMT, root@hip-hop.suvl.ca.us (Remco
: >>> Treffkorn) said:
:
: Remco> Listen, the point here is simply that some people are wondering if the
: Remco> SCSI performance is all the way up there *or* if it could be improved.
:
: Oh yes, several.
:
: Remco> Natually they are comparing notes. The problem is only that nobody
: Remco> can agree on the correct way to measure performance. Iozone is certainly
: Remco> not perfect, but gives you a relative measure if compiled correctly.
:
: Yes, it gives you a relative measure, but perhaps it is not of disk
: performance.
You are right, you get an idea of the performance of the complete subsystem.
:
: 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 ? ;-)
: 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.
:
: My *impression* is that the SCSI drivers are rather OK (e.g. by
: comparison with SVR4, which has some hideously inefficient drivers), in
: that they have relatively little delay and consume relatively little
: CPU, and 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?
:
: b) advising for expected access patterns should be
: possible/automatic.
Right, but sequential writes do not benefit too much from it.
:
: c) the cache code should be eliminated (mmap'ing everywhere).
:
: d) the allocation clustering algorithm could be improved.
:
I tend to agree with your list in part. I still *feel* that with what
there is the performance should be better.
If something in the current code is suboptimal no amount of redesign work
will reach its full potential, unless you design the offending code out.
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.
: Point c) is being done by Linus Torvalds; but it can have a severely
: negative performance impact, as Sun discovered a couple years ago,
: unless it is done after b).
:
: Doign a) and d) would not be too difficult, and would eliminate the need
: for blocks and fragments (a poor idea anyhow).
:
I would like to be absolutely sure that the current code (driver, fs, cache)
is optimal before making design choices based on 'the look of things'.
Otherwise it is like driving your VW Bug with the parking break on and
putting a Porsche engine in to be able to go as fast as other Bugs.
Certainly solves the problem though ;-)
Remco
remco@hip-hop.suvl.ca.us DC2XT