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.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
