From owner-freebsd-current Sun Aug 11 5:38:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C48DF37B400 for ; Sun, 11 Aug 2002 05:38:09 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90DBA43E72 for ; Sun, 11 Aug 2002 05:38:08 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA09885; Sun, 11 Aug 2002 22:38:01 +1000 Date: Sun, 11 Aug 2002 22:42:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Maksim Yevmenkin , Subject: Re: Interrupt vs. polling on -current In-Reply-To: <3D555FAD.A4137491@mindspring.com> Message-ID: <20020811222403.C20418-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message