> From: Doug Ledford <dledford@dialnet.net>
> Date: Sun, 20 Sep 1998 20:55:42 -0500
>
> No, I fully agree with you that we shouldn't chain ourselves to something, I
> was just pointing out that there is an actual reason to argue over the
> correct usage of SA_INTERRUPT in 2.0.x since many of us are still
> maintaining drivers there. My original arguments were basically that I
> don't think SA_INTERRUPT really buys a SCSI driver anything so I personally
> thought Gerard should take it out of his driver since doing so would solve
> other problems. However, if the ncr cards can generate as many as 10,500
> interrupts per second, maybe his driver does need the SA_INTERRUPT flag :)
Sad to see this flags, that allowed to prevent from sharing IRQ with
PCI NE2000 boards, has gone away. ;-)
> It's not just his driver either. In certain cases I've managed to clock over
> 13000 interrupts/second on a single host aapter, and multiple host adapters
I'm interested in knowing which OS/driver/controller/benchmark gives
such a result, if possible to tell us more about.
> just magnify this. The real issue with SA_INTERRUPT is not wanting unnecessary
This benchmark is 1 KB IOs chunks through the block device (read
ahead turned off) including the caching of linux, using:
- A Viking II that is unable to perform more than 5500 IOs/sec.
- A Cheetah2 that performs at least 7500 IOs/sec.
In this benchmark the both disks complete at the same time, indicating
that the Viking II forces its speed for the Cheatah.
(PII 233 + 53C895)
So, it must not be considered as the maximum number of 1 K IOs/sec the
couple driver/895 is able to perform.
I get this with the new experimental driver that uses LOAD/STORE instead
of legacy MEMORY MOVE scripts instructions (dropping old 810 and 825
support at the same time).
The stock ncr driver gets about 8700 IOs/s for the same benchmark.
My calculations let me think I could get more than 13000 1KB IOs / second
using 2 Cheatah2, but I have only one.
> bottom half processing, not the slower interrupt trap entry/exit sequences. As
> has been suggested multiple times before, a reasonable way to get rid of
> SA_INTERRUPT is to allow interrupt handlers to return a value indicating
> whether they need bottom half processing or not, and OR together the results
> from all the interrupt handlers sharing an interrupt.
Not needing post processing of an event gotten from interrupt probably
means that the interrupt routine did too much work under interrupt context
or that you did'nt catch any event. You may be called without any pending
event when you are sharing the IRQ, but generally at least one of the
interrupt handlers that share the IRQ has a pending event on each
interrupt. So, BH handling has to be started most of the time on interrupt
when things are done as they shall be.
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/