On Sat, 10 Aug 2002, Terry Lambert wrote:

> Bruce Evans wrote:
> > No, but the 3Com driver apparently is.  The sio driver wants to have
> > fast interrupts.  It can't have them with the irq is shared, so its
> > worst-case interrupt latency for a single serial port is increased
> > from about 50 usec to many msec, depending other interrupt activity
> > in the system (not limited to that for the shared irq except in some
> > configurations).  Silo overflows occur at 115200 bps when the latency
> > is more than about 1.5 msec.
> Anyway to get the code to complain about the sharing of serial
> interrupts?

It already complains: from sio.c:

%               ret = BUS_SETUP_INTR(device_get_parent(dev), dev, com->irqres,
%                                    INTR_TYPE_TTY | INTR_FAST,
%                                    siointr, com, &com->cookie);
%               if (ret) {
%                       ret = BUS_SETUP_INTR(device_get_parent(dev), dev,
%                                            com->irqres, INTR_TYPE_TTY,
%                                            siointr, com, &com->cookie);
%                       if (ret == 0)
%                               device_printf(dev, "unable to activate interrupt in 
fast mode - using normal mode\n");

> Also, if there is a PCI interrupt for the serial (serial handled
> by Northbridge... I'd like to see this, actually), shouldn't it
> be capable of sharing *only* fast interrupts somehow?  It's an

Yes, this should work.  It mainly needs a multiplexer like the old one
for ordinary shared irqs (but even simpler since it doesn't need or
want to change the ipl (soft or hard)) and lots of configuation cruft.

> obvious pessimization to mix other interrupts with fast interrupts,
> but less obvious what would happen with fast + fast...

It's more than a pessimization; it is impossible by definition, since
sharing fast interrupts (at the same time) makes them non-fast.  Another
thing that bus_setup_intr() doesn't do is transparently enough is changing
the setup as devices with different requirements come and go.

> > FreeBSD on a 486/33 can handle about 40000 serial interrupts per second
> > to do one character of i/o per interrupt).  Pessimizations in -current
> > have only degraded this by a small factor (2?), provided the driver
> > uses fast interrupts.  Lose another small factor (2?) for normal interrupts
> > (using normal interrupts only loses a large factor for latency).
> Any way to fix this, short of "don't run -current"??

There's also "use a fast CPU (almost any new one)".  Some of the overheads
are related to I/O, so you won't noticed 2x or 4x pessimizations of software
overheads once the I/O overheads are very dominant.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to