From owner-cvs-all Sat Dec 22 19:38:21 2001 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F0A7B37B416; Sat, 22 Dec 2001 19:38:14 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBN3cCe99476; Sat, 22 Dec 2001 19:38:12 -0800 (PST) (envelope-from dillon) Date: Sat, 22 Dec 2001 19:38:12 -0800 (PST) From: Matthew Dillon Message-Id: <200112230338.fBN3cCe99476@apollo.backplane.com> To: Bruce Evans Cc: Mike Silbersack , , Subject: Re: cvs commit: src/sys/dev/sio sio.c References: <20011223141152.Y10385-100000@gamplex.bde.org> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :I fixed the software problems in 386BSD-0.0. Software latency bugs :are occasionally reintroduced. -current has several problems in this :area. They are mostly design problems so they are hard to fix. However, :I think the latency problems in -current only break sio on old machines. :IIRC, spinlocks are never held for more than about "only" 2000 (or is :it 0x2000) instructions. On a 386/20, 2000 instructions took something :like 400 usec, but on not so modern machines (1GHz) it takes more like :4 usec. The driver needs a latency of less than about 75 usec to work :for all supported hardware. : :Most silo overflows seem to be caused by video hardware hogging the bus. : :Bruce And I've written serial drivers for 8085, 8086, 68000, 68008, 68020, 68030, Perkin-Elmer (my god! Interrupt driven microcode!), 68xx, 683xx, 486's (in assembly), etc etc etc etc. I am not insensitive to interrupt latency issues or unknowledgeable. On a 16MHz 68000 I was able to write a serial interrupt handler that took less then 5uS per character (inclusive of *all* interrupt overhead). On a 486 it took a little longer due to all the ISA accesses. In anycase, it's moot on a modern day machine. The PCI/ISA accesses alone eat more cpu then all the rest of the instructions combined. If our users are running X sessions and trying to operate a dialup link, we have to support that. Setting the FIFO level to MEDHI is totally and completely reasonable. Since National screwed up the design of the 16550[A] from day 1 (and it is STILL screwed up), we have had to live with it and that means dealing with these issues so our users don't have to. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message