Date: Mon, 27 Apr 1998 22:44:53 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Mail Receiver <rmail@ittc.ukans.edu> Cc: aic7xxx@FreeBSD.ORG Subject: Re: Duration of Blocked Interrupts Message-ID: <199804280444.WAA21867@narnia.plutotech.com> In-Reply-To: <Pine.LNX.3.95.980427202026.30468B-100000@hegel.ittc.ukans.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.LNX.3.95.980427202026.30468B-100000@hegel.ittc.ukans.edu> you wrote: > > We're interested in trying to minimize this in one of two ways. For > certain processes, we'd like to either block their access to the driver > (by queueing them up upon entry and leaving them blocked there until we > decide to let them through) or limit the number of outstanding requests > they can have (again, by blocking them temporarily). Alternatively, if > there are any ways to minimize the number of passes through the main loop > in the ISR, we'd like to investigate them. We're willing to sacrifice > some of the performance for predictability (especially up front, we can > work on optimizing it later). > > Any pointers or suggestions would be greatly appreciated. First of all, excuse my ignorance of Linux kernel internals. I'm a FreeBSD hacker by trade... But, I believe that Linux has what is called a "bottom half handler" which is somewhat similar to a software interrupt handler that can be preempted by other interrupts. If this is the case, I would suggest modifing the aic7xxx interrupt handler into a two phase process. First, traverse the list of pending completed commands and stuff them into a queue. This should complete very rapidly. Then, perform the completion processing, which is a lengthy process through the generic SCSI layer, from the bottom half handler. If the bottom half handler is blocking user processes for too long, you can have it process at most X completions at a time and schedule itself to run again at a later time. You might want to look at the Linux BusLogic/Mylex MultiMaster/Flashpoint driver which appears to use a deferred completion mechanism. The FreeBSD CAM SCSI layer, which I'm more familiar with, defers upper level completion processing. All completion processing is deferred until you are out of hardware interrupt contexts so it can be pre-empted by more interrupts (even from the same device that queued the work). The result has been an increase in performance for applications that require fast interrupt response (ethernet controllers for instance). Good Luck! -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804280444.WAA21867>