> And you can fill in my usual flame about people writing drivers that use
> SA_INTERRUPT on shared interrupt lines. (Perhaps if they would have been
> called "ugly interrupt" instead "fast interrupt"...)
There is no semantic problem for a driver to tell the kernel its interrupt
code is fast when it is _actually_ fast.
On the other hand, the fact that an IRQ may be shared is an hardware
requirement for PCI and a kernel not allowing this sharing is broken.
Seems to me you are blaming SCSI low-level drivers without naming them.
The IRQ latency problem we observe in the SCSI layer is not the fault of
SCSI low-level drivers. Their _own_ interrupt code is generally _fast_,
as all interrupt code is required to be on a serious O/S.
The problem is in the callback mechanism that does too much work in
interrupt context instead of just queuing the control block and doing
the slow work outside any interrupt context.
IIRC this has been fixed in the 2.1 SCSI code, but needs low-level drivers
to be changed in order to gain advantage of callback queuing and BH
handling. The last time I had time to make appropriate changes in the ncr
drivers, the new SCSI code was fairly broken and I gave up. I have planned
to restart this work but need time for.
Your flames about IRQ handling hasn't have the effect you expected for the
simple reason they were not targetted to the right persons. It was a
kernel architecture issue and a SCSI generic layer driver issue and you
flames always were against the low-level drivers that were exactly the
_wrong_ target with regards to the problem.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/