Date: Thu, 31 May 2001 09:34:54 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: freebsd-alpha@freebsd.org Subject: Abyssmal interrupt latency with -current Message-ID: <20010531093454.X89950@gsmx07.alcatel.com.au>
next in thread | raw e-mail | index | archive | help
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. As a comparison, my 386SX-25 running 2.2.5 can run PPP at 38.4kbps without SILO overflows using a 16450 UART. My Multia running -current gets SILO overflows at 38.4kbps with a 16550A set to interrupt at 8 bytes (even after I disable WITNESS and INVARIANTS). This is an order of magnitude worse performance. To try and get a handle on the problem, I added code to read and save the PCC at the start of XentInt() [this is as close as I can get to when the interrupt was raised], siointr() [this is when the interrupt is delivered to the device's interrupt handler] and siointr1() [which is after the sio mutex is seized and close to when the received character is actually read]. The code is not yet perfect, but I'm reasonably confident about the accuracy of my results. (These figures are for a UP kernel from late last week without WITNESS or INVARIANTS). The median time from entering XentInt to the start of the sio interrupt handler is 61usec. This should be similar for any interrupt handler. I suspect the brain-dead memory interface on the LCA is a significant factor in this. This also implies that the clock interrupt overhead is 15-20% of CPU time - I might try to configure a real stats clock interrupt and see if I can get accurate figures. Once control actually gets to siointr, grabbing the sio mutex takes another 2.7usec (median) - again quite high. Whilst these figures are very high, they would be survivable if it wasn't for the figures to the right of the median... The mean time between XentInt and siointr1() is 223usec. In my sample of 1650 serial interrupts over 4.8 seconds, there are 3 outliers at ~55msec and another 2 at ~7msec. In all, nearly 1% of the samples have a latency exceeding 2msec. (My samples show that multiple clock interrupts occur between when the serial interrupt is received in XentInt() and when it gets handled in siointr1()). It's possible that some of these samples are glitches in my collection code, but the existence of SILO overruns means that the latency can exceed ~2msec. Does anyone have any ideas what could be leading to such ludicrous interrupt latencies? 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. 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?20010531093454.X89950>