Date: Sun, 17 Oct 1999 23:13:39 -0600 (MDT) From: "Kenneth D. Merry" <ken@kdm.org> To: mjacob@feral.com Cc: groudier@club-internet.fr (Gerard Roudier), cdf.lists@fxp.org (Chris D. Faulhaber), gallatin@cs.duke.edu (Andrew Gallatin), scsi@FreeBSD.ORG Subject: Re: FreeBSD 3.2 / Slow SCSI Dell PowerEdge 4300 Message-ID: <199910180513.XAA70335@panzer.kdm.org> In-Reply-To: <Pine.BSF.4.05.9910161037490.11481-100000@semuta.feral.com> from Matthew Jacob at "Oct 16, 1999 10:44:10 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote... > > > What seems to happen when tagged command queuing is disabled, is that the > > IO scheduling policy can stay a long time (seconds) on one IO stream and > > 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 the > > supposed multi-threaded IO streams become a succession of single-threaded > > IO streams that may each last seconds. > > It's conceivable that with tagged queing there *shouldn't* be a disksort > function on the processor except with respect to synchronization > barriers. Well, we could disable the sort for tagged queueing drives, and enable it for drives that aren't capable of it. The only complication would come when tagged queueing is enabled/disabled for a given drive. I suppose it wouldn't be that complicated, though. You could probably just switch back and forth between bufqdisksort() and bufq_insert_tail() without too much trouble. The transport layer necessarily does things a little differently, but my guess is that it probably wouldn't do too much harm in the bufq to just switch on the fly. Before we go off and do anything like that, though, someone (i.e. not me) should probably do some benchmarks and see just what the difference is between sorting and not sorting. This may largely depend on how deep the bufq in the da(4) driver gets. If it doesn't get very deep, it won't make much difference whether you sort or not. And what do you mean by synchronization barriers? Ordered writes? If you aren't sorting, you're putting things through in FIFO order, and so every write ends up being an ordered write. (bufqdisksort() just uses bufq_insert_tail() if the request in question is B_ORDERED, and then everything before that in the queue is locked against any change in ordering.) Ken -- Kenneth Merry ken@kdm.org 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?199910180513.XAA70335>