Date: Sat, 16 Oct 1999 21:38:15 +0200 (MET DST) From: Gerard Roudier <groudier@club-internet.fr> To: Matthew Jacob <mjacob@feral.com> Cc: "Kenneth D. Merry" <ken@kdm.org>, "Chris D. Faulhaber" <cdf.lists@fxp.org>, Andrew Gallatin <gallatin@cs.duke.edu>, scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Message-ID: <Pine.LNX.3.95.991016211142.659A-100000@localhost> In-Reply-To: <Pine.BSF.4.05.9910161037490.11481-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 Oct 1999, Matthew Jacob wrote: > > What seems to happen when tagged command queuing is disabled, is that t= he > > IO scheduling policy can stay a long time (seconds) on one IO stream an= d > > then switch to another one, and so on ... This seem to be due (just > > guessing) to a side effect of the disksort algorithm that just makes th= e > > supposed multi-threaded IO streams become a succession of single-thread= ed > > IO streams that may each last seconds. >=20 > It's conceivable that with tagged queing there *shouldn't* be a disksort > function on the processor except with respect to synchronization=20 > barriers. Just disksort + asynchronous read-ahead and 1 IO at a time seems to make the O/S choose the same IO stream for a too large amount of time. Other IO streams may starve a too long time leading to bad interactivity.=20 A disksort is certainly not a bad thing, but some simple heuristic that avoids the above should be considered.=20 > > If I am right (fill free to fix me if needed), it is actually the OS th= at > > might be inadequate for tagged command queuing benchmarking. Bug or > > feature ? ;-) >=20 >=20 > Hard to say.=20 Not for me, by the way. ;-) > Depends on the job mix. The same arguments were advanced > (successfully in some cases for the time) to either disable > using disconnect/reconnect or also, in one classic case at Sun, to hang > out in the interrupt service routine "a bit" when getting status to also > get the command complete without having to take another (expensive) > interrupt (quite different hardware than the current set). Hmmm... This can only happened with too old or poor designed SCSI controllers. Well designed SCSI controllers do not interrupt uselessly. About disabling SCSI disconnections, I would have been glad not to have read that. Note that I am not going to ever choose a SUN originated system for numerous reasons. ;-) > I suspect that the right thing here is to to ultimately do completely > adaptive scheduling with hints- this would also solve the arguments I May be, a simple but kind bug that add some mess-up to disksort would solve the problem. :-) > constantly have with Matt Dillon over whether MAXPHYS is too small at > 128KB (it most certainly is if you have a job mix that's mainly large > sequential writes or reads)- but until that point, document the tools tha= t > allow you to tune things and tell users "Knock yerself out... have a grea= t > time!" I have measured 35MB/s throughtput on a 80MB/s LVD SCSI BUS using 4K actual IO chunks. This let me think that 64 KB is not that small given not ridiculouly high IO latency. May-be for Ultra-160 (and probably for future Ultra-320), 64KB will be to small. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.991016211142.659A-100000>