Date: Mon, 24 Dec 2001 16:22:47 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: David Greenman <dg@root.com>, Bruce Evans <bde@zeta.org.au>, 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: <20011224162247.B85044@gsmx07.alcatel.com.au> In-Reply-To: <61654.1009097922@critter.freebsd.dk>; from phk@critter.freebsd.dk on Sun, Dec 23, 2001 at 09:58:42AM %2B0100 References: <20011222193231.D24034@nexus.root.com> <61654.1009097922@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 23, 2001 at 09:58:42AM +0100, Poul-Henning Kamp wrote: >Bruce has a very valid point here: If our bad^H^H^Hlousy interrupt >latency is not visible to developers, people will not think about >it until our entire kernel has become a slow monster. Then the logical solution would seem to be to use FIFO_RX_HIGH in -CURRENT and change it to FIFO_RX_MEDH in -STABLE. This fits into the same category as the malloc(3) defaults in -CURRENT which are designed to flush out mis-behaving programs. An even better solution would be to make this a sysctl or automatically tune itself. >The rest of the project doesn't notice lousy interrupt latency >until timecounters overflow or serial ports drop characters. I'm not sure that even FIFO_RX_HIGH is enough to flush out the problems. Earlier this year, there was a bug in the Alpha that resulted in all interrupts being scheduled as threads. AFAIK, I was the only person who noticed (and in my case, I was still getting SILO overflows at 38.4kbps with FIFO_RX_MEDH). >My guess would be that only four people in the project who have >ever measured our interrupt latency: Bruce, Louie, Warner and me. That's definitely an under-estimate. Andrew Gallatin posted his latency measurements on a Alpha h/w. I think I've seen one or two other people indicate that they'd made measurements on -hackers. I've also done some limited latency testing on both i386 and Alpha's. >If our interrupt latency is so bad that we cannot run a serial port >as well on a PIII/Athlon 1GHz cpu as we could on a 486/66 a few >years back, then the solution is not to make the serial driver more >defensive, the solution is to fix the interrupt latency. Unfortunately, I can't see this happening. 1) The migration of the PC-card interface to Cardbus means that PC- card devices no longer have the option of a fast interrupt. This will bite everyone who uses a laptop without a real builtin modem. 2) -CURRENT seems to be moving further towards having all interrupts handled via kernel threads, rather than in real time. Peter 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?20011224162247.B85044>