Duration of Blocked Interrupts

[Justin T. Gibbs]

In article <Pine.LNX.3.95.980427202026.30468B-100000 at 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 at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message