Date: Thu, 19 Sep 1996 11:04:24 +1000 From: Bruce Evans <bde@zeta.org.au> To: BRETT_GLASS@infoworld.com, hardware@freebsd.org Subject: Re: More or fewer IRQs? Message-ID: <199609190104.LAA20566@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I'm setting up a FreeBSD system with a buncha serial ports, and the cards
>will allow me to share IRQs between ports. There are 5 available IRQs and
>10 ports; in other words, there aren't enough IRQs to allow every port to
>have one of its own, so some sharing is necessary.
>With the hardware I have here, I have two choices. I can use up every IRQ
>in the machine and put two UARTS on each, or I can lump more together
>(there are three ISA cards, so that means I could get away with using 3 out
>of the 5). The latter approach has the advantage that I can add another
>peripheral in the remaining vacant PCI slot and would have an IRQ for it.
>But which would yield better performance?
Try it and see. "Some sharing" forces you to use the inefficient
COM_MULTIPORT options for all ports (even ones on an unshared IRQ),
so many of the advantages of not sharing aren't available. The main
advantage of putting all the ports on one IRQ gives less unfair
sharing but probably costs more. On machines with fast CPUs and cache,
approximately:
(1) per-interrupt cost for _each_ additional shared port
= 1.5 * time for one inb(0x3fa)
= about 2 uS for 8MHz ISA bus
(2) per-interrupt cost
= time for one outb(0x20, 0x20) (if !AUTO_EOI_1 option)
+ time for one outb(0xa0, 0x20) (if IRQ >= 8 && !AUTO_EOI_2 option)
+ about 1-10 uS for CPU overheads (1 uS on P90, 10 uS on 386)
+ time for cache misses
+ more for lots of output completions and modem status changes
= it depends
>It seems to me that the high
>overhead of taking an interrupt MIGHT make it better to put many ports on
>one IRQ, since polling each port on the card probably still costs less than
>a context switch on an Intel CPU (a truly ugly process ;-). On the other
Interrupt overheads are only relatively high. They are only a couple of
times more than the overhead for one inb() to poll one port, at least if
inb()s to access the ICU are avoided. Interrupts aren't context switches,
so the higher overheads and uglyness for context switches don't apply.
>hand, the source code suggests that the driver turns off interrupts as
>it services serial ports, so there MIGHT be a chance of starving otner
>devices (in particular, the system's cantankerous IDE interface) if
>there were many UARTs on an IRQ. What say ye?
The other devices would starve anyway, since (sio and cy) serial devices
have priority. IDE doesn't mind starving for hours. However, the
serial drivers try to be fast, since they would starve their own 8250
devices if they took more than 86 uS. They do take more than 86 uS if
there is a lot of activty on a lot of ports. The maximum is about 1000
uS for 16 ports at 115200 bps. 2000 uS for 32 ports at 115200 bps can't
work because the next batch of input will arrive after about 14 * 87 =
1218 uS.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609190104.LAA20566>