Date: Mon, 11 Aug 1997 21:57:12 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Doug Ledford <dledford@dialnet.net> Cc: "Daniel M. Eischen" <deischen@iworks.InterWorks.org>, welbon@bga.com, aic7xxx@FreeBSD.ORG Subject: Re: aic7xxx / AHA2940 worries... anyone? Message-ID: <199708120357.VAA03849@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 11 Aug 1997 00:09:20 CDT." <199708110509.AAA11039@dledford.dialnet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> >In any case, Justin, is there any word on the possibility of getting the >sequencer to check the qoutfifo's status before putting a command on there, >and spin locking if the queue is full (any elegant ideas on how to do this >if we can't read the QOUTCNT register inside the sequencer)? It seems to me >that this problem is going to be worse in scenarios like the bonnie test >where you have large numbers of closely grouped writes where the drive could >download a write's data, cache it, get the next write's data, cache it, >write several of these out in a single spindle pass, then come back to the >controller with multiple COMMAND_COMPLETES at very short intervals, >especially with lots of drives in use. For things like this we very well >could need to add this item back into the sequencer. One final thing, >Justin, do you happen to know for certain what happens with the QUOTCNT >register if the QOUTFIFO does overflow? Does it stay at 16 (on the 2940 >chips anyway), or does it wrap back to 0 or what? At one point I did add a combination of code into the sequencer and kernel to "spin-lock" if the queue became full. In reality, it shouldn't be necessary unless there is extremely high interrupt latency. The algorithm I used in the past was to keep a count in scratch ram and in the driver of the number of commands that have been entered/removed from the queue. When that count reaches the full count value, the kernel driver pauses the sequencer and clears the counter to 0. This approach limits the number of accesses (and hence pause operations) that need to be performed and, given sufficiently low interrupt latency, should make hitting the spin lock a low probability since you have one full command completion time to enter your interrupt routine and clear the counter. I should probably re-introduce this into the FreeBSD driver in the short term since the driver currently in the source tree does have "high completion queue processing latency". We get into the interrupt handler soon enough to keep the queue drained, but each command that is removed from the queue is handed up to the higher SCSI layers for what can be a large amount of work. This makes queue draining a sometimes slow process. I haven't been touching the driver in the source tree much lately though since I'm working on a new SCSI layer that uses a very different driver. I will have to do some measurements to ensure that this is the case, but since completions are handled in a separate software interrupt context in this new code, with the hardware interrupt handler rarely blocked and it's usual task of queuing up the command blocks for completion processing extremely quick, I don't think that a spin lock will be required. The new driver also adds better support for multi-lun devices, 255 command "indirect" SCB paging for the aic7770, aic7850, and aic7860, and a much better error recovery model. It's much more interresting to work on than the old driver to work on. 8-) As for what happens when you attempt to stuff an entry into a full queue on the aic7880, aic7870, and aic7770, the data book says that it is a no-op. The aic7850 data book says that the QOUTCNT will increment. As always, any claims that the data books make should be verified by experiment. >-- >***************************************************************************** >* Doug Ledford * Unix, Novell, Dos, Windows 3.x, * >* dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician * >* PPP access $14.95/month ***************************************** >* Springfield, MO and surrounding * Usenet news, e-mail and shell account.* >* communities. Sign-up online at * Web page creation and hosting, other * >* 873-9000 V.34 * services available, call for info. * >***************************************************************************** > > > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708120357.VAA03849>