Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!decwrl!netcomsv!netcom.com!thinman From: thinman@netcom.com (Technically Sweet) Subject: Re: Excessive Interrupt Latencies Message-ID: <1993Mar19.221353.14068@netcom.com> Organization: International Foundation for Internal Freedom Date: Fri, 19 Mar 1993 22:13:53 GMT Lines: 37 My experience hacking the at&t unixes for 286 and 386 for the past 6 years has convinced me that emulating the pdp-11 SPL tower is silly. The PDP-11 interrupt chain is designed so that interrupt routines with tight response requirements can come in on top of interrupts with loose response requirements. That is, a serial port with no buffering can come in on top of a hard disk operation. The disk keeps spinning, so it's no great loss if it misses a revolution. But, another character could come in and stomp the current one. This rationale is obsolete. There are buffered serial ports available for the PC, and even the unbuffered ones are so slow compared to a 386/20 that there's no reason for prioritized interrupts. A Unix house (Philips in the NL) did a streams-based terminal handler on Unix v.3.2 and found that the processor was spending 20% of it's time in the spl-code emulation of the SPL tower. This is an extreme, but it indicates how the emulation causes other problems in a chain reaction. Here's an experiment: replace all spl1-n() calls with disable-interrupt, and spl0 with enable-interrupt. Change all interrupt handlers so that they only do what needs to be done and delay the rest to a "soft interrupt" routine. It's likely that the system will work just fine, with no long-latency periods. If not, well, you've learned some serious kernel hacking skills :-) -- Lance Norskog thinman@netcom.com Data is not information is not knowledge is not wisdom.