Shared IRQ clarifications for Vortices/Adaptecs et al.

Donald Becker becker@cesdis1.gsfc.nasa.gov
Tue Feb 16 11:27:57 1999


On Mon, 15 Feb 1999 Ted_Rule@flextech.co.uk wrote:

> Donald Becker has made reference here previously to his document:
>  http://cesdis.gsfc.nasa.gov/linux/misc/irq-conflict.html
> which outlines various issues associated with Shared IRQ usage in various
> drivers.
...
> a)   The aic7xxx.c driver snippet below performs a "request_irq SA_SHIRQ "
> before a
> "request_irq SA_INTERRUPT | SA_SHIRQ". Is it therefore immune from the
> SA_INTERRUPT problem as
> if an interrupt is available, the first call to request_irq will succeed and the
>  second never gets performed?

This is a change to the aic7xxx  driver.  I believe it used to perform the
SA_INTERRUPT attempt first, and only do the correct SA_SHIRQ if it failed.
(see next)


> b)   The advansys.c driver does things the other way round. So presumably it is
> NOT immune to the SA_INTERRUPT
> problem, and ought to be corrected?

A driver that uses shared interrupts should *never* use SA_INTERRUPT.
The aic7xxx presumably changed the order to correct its behavior where
possible, but to still work with the other SCSI drivers if needed.


> c)   The 3c59x.c and tulip.c drivers only ever call request_irq with SA_SHIRQ. I
>  take it that this is therefore the only correct way to call
> request_irq? Or is this only true for a PCI device? Presumably ISA device
> drivers are called with no SA_ flags - a quick glance at several
> network drivers seems to suggest this is so.

No ISA device can share interrupts -- this is a hardware limitation.
The only device that should use SA_INTERRUPT is the old serial port code,
which limited its interrupt work to removing a single character.  Almost
every other device type does more work at interrupt time.

> d)   The ThunderLAN driver tlan.c seems to only call request_irq with
> SA_INTERRUPT if its sa_int flag is set for the instance in question.

This is solely to work around the SCSI problem.
It's semantically incorrect.

> e)   Is there a performance advantage ( significant or otherwise ) to be had
> with running different cards on non-shared interrupts? In particular
> is it better performance-wise to run one's 100BaseTx network card and SCSI
> Controller on different IRQ's..?

 Using seperate interrupt lines avoids overhead with each interrupt.
 If you mate busy with low-interrupt-rate devices this overhead will be at
 its worst.  For every interrupt the system must call every attached
 interrupt handler, most of which will be idle.

 If you have two simultaneously busy devices the combined handler might
 aggregate work and mitigate the interrupt entry overhead.  This is most
 likely true with a few ethernet drivers that use 'interrupt mitigation' to
 defer raising an interrupt (e.g. most of the time you don't immediately
 need to know that a packet has been transmitted).

 If you have only low-interrupt-rate devices sharing an interrupt, the
 overhead doesn't matter.


Donald Becker					  becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882	     http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html