Date: Sat, 20 Sep 2003 14:29:34 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-arch@freebsd.org Subject: Re: interrupt latency and driver locking Message-ID: <XFMail.20030920142934.jdp@polstra.com> In-Reply-To: <20030920141158.B97439@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20-Sep-2003 Luigi Rizzo wrote: > > what i mean is that i don't think the frequency of these events (once per > second or lower) is a big issue, but it is the fact that > when they hit they delay potentially urgent activities for > possibly very long times. > In fact, the 50..300us measured by Sam are not even the worst case; > I am pretty sure that when you have an actual PHY change the > delays involved can be much longer, I think we are basically in agreement that this needs to be fixed and that it will involve a separate lock. I care less about actual link changes than I do about the polling, because in a typical stable setup there will be no link changes except at bootstrap and shutdown. > e.g. if you do an 'ifconfig' > involving a media change (or even the initial 'up'), the "em" driver > does a busy wait of well above 1 second while in the interrupt > to wait for the autoconfig to settle (with DEVICE_POLLING this > hits you badly). Several other drivers have similar issues. Yes, the em driver is especially nasty in this regard. I think maybe changing the #define of WAIT_FOR_AUTO_NEG_DEFAULT to 0 in "if_em.h" would fix it, but I haven't tried that. > This is why i advocate a design change so that non-real-time, > time-consuming activities are run under a different lock > that does not block other real-time activities (for other > subsystems of course). Yep, me too. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030920142934.jdp>