From owner-freebsd-arch@FreeBSD.ORG Sat Sep 20 14:29:36 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D900E16A4B3 for ; Sat, 20 Sep 2003 14:29:36 -0700 (PDT) Received: from blake.polstra.com (mail.polstra.com [206.213.73.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id A094E43FB1 for ; Sat, 20 Sep 2003 14:29:35 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by blake.polstra.com (8.12.9/8.12.9) with ESMTP id h8KLTZIL016435; Sat, 20 Sep 2003 14:29:35 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030920141158.B97439@xorpc.icir.org> Date: Sat, 20 Sep 2003 14:29:34 -0700 (PDT) From: John Polstra To: Luigi Rizzo X-Bogosity: No, tests=bogofilter, spamicity=0.500053, version=0.14.5 cc: freebsd-arch@freebsd.org Subject: Re: interrupt latency and driver locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2003 21:29:37 -0000 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