Duration of Blocked Interrupts

[Doug Ledford]

Justin T. Gibbs wrote:
> 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.

There is one for the network devices already.  There isn't one for the SCSI
drivers.  If you want one, you have to build it yourself.

> 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.

A deferred handler is creatable under the 2.0.x kernels to a point.  There
are a couple "gotchas" lurking in there.  For instance, the kswapd daemon
will block the scheduler from running when it is specifically waiting on a
swap operation that's needed immediately.  The downside to this behaviour is
that *all* bottom half handlers based on anything other than a hard IRQ
source will be blocked as well.  This leads to the chicken and egg problem
if you built your bottom half handler around something such as the scheduler
task queue.  The scheduler task queue won't get run because the scheduler is
blocked waiting on a swap operation to complete, and the swap operation
can't complete because your waiting on the scheduler to run in order to do
completion processing.  In that case, I used a backup IRQ source from the
timer interrupt to generate completion events when the scheduler was
locked.  This has the downside of putting things right back into an
interrupt context during these blocks.  The reason I used the scheduler task
queue for normal completions is because it was the only one that didn't
create performance bottlenecks due to overly delayed processing of small
commands.  The 5.0.x driver included this kind of bottom half processing in
the earlier versions, but it was taken out later due to swap latency
problems introduced by the bottom half handler.  There was a more than
noticeable difference in swap performance when you only had one swap
partition or file due to the fact that you were constantly waiting on the
timer interrupt to complete swap operations that were small in size.  This
generated a 100 operation per second limit that was unacceptable to many in
performance.

> 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).

This is "in the queue" so to speak for 2.3.x kernels, but the 2.2 kernels
won't get this feature mainly due to time constraints.

-- 

 Doug Ledford  <dledford at dialnet.net>
  Opinions expressed are my own, but
     they should be everybody's.

To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message