Date: Sat, 22 Dec 2001 19:32:31 -0800 From: David Greenman <dg@root.com> To: Bruce Evans <bde@zeta.org.au> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Mike Silbersack <silby@silby.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/sio sio.c Message-ID: <20011222193231.D24034@nexus.root.com> In-Reply-To: <20011223141152.Y10385-100000@gamplex.bde.org>; from bde@zeta.org.au on Sun, Dec 23, 2001 at 02:29:02PM %2B1100 References: <200112230252.fBN2qVm99224@apollo.backplane.com> <20011223141152.Y10385-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>On Sat, 22 Dec 2001, Matthew Dillon wrote: > >> I've gone through the logs of sio.c and I see no requirement >> that changes be approved by anyone, nor do I see any Approved: >> lines in the commit messages. Your backing out of my patch was >> totally inappropriate and I have re-committed it. > >If you don't know who is the author and maintained of this driver then >you have no business touching it. > >> Your explanation is also seriously flawed considering the endemic >> problem silo overflows have been over the last few years. If you >> want to set the FIFO levels to high, you should first fix the >> problems in the system causing the long interrupt delays. Otherwise, >> leave it at MEDHI. MEDHI is perfectly reasonable. > >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. It seems to me that these days it is more important to optimize for reducing overflow due to latency than it is to optimize for reducing overflow due to interrupt overhead. A trigger that is set near the median of 8 seems like the most reasonable setting to me when considering modern hardware. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011222193231.D24034>