Date: Mon, 04 Jun 2001 10:42:32 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: freebsd-alpha@FreeBSD.ORG Subject: Re: Abyssmal interrupt latency with -current Message-ID: <20010604104232.V89950@gsmx07.alcatel.com.au> In-Reply-To: <20010531093454.X89950@gsmx07.alcatel.com.au>; from peter.jeremy@alcatel.com.au on Thu, May 31, 2001 at 09:34:54AM %2B1000 References: <20010531093454.X89950@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-May-31 09:34:54 +1000, Peter Jeremy <peter.jeremy@alcatel.com.au> wrote: >I've recently been getting SILO overflows on the PPP link on my >Multia. I recall seeing a comment (probably in -current) about >interrupt latency regressions, but the Multia seems worse than >my 486, so I suspect some of it is alpha-specific. And I found that it is... see alpha/27866. Basically `fast' interrupts aren't detected as fast and are being scheduled as threads. Note that this bug would have been detected by the compiler if we were using a type-safe language. >The median time from entering XentInt to the start of the sio >interrupt handler is 61usec. With my fix in, the mean and median both drop to just over 21usec, with a range of 10..~129 usec. The worst case is fairly bad, but is good enough to allow sio to work. The reason for the large worst-case latencies are nested interrupts - especially clock interrupts. (These figures are for a UP, not SMP kernel). >Overall, I suspect I'd be better off ignoring all interrupts except >the clock interrupt and polling everything everything else from >within the clock interrupt. I'm still considering this. The only problem I see is for receiving lots of small ethernet frames (the Multia only supports 10Mbps, so a large frame takes >1msec). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010604104232.V89950>