From owner-freebsd-arch@FreeBSD.ORG Sat Sep 20 14:12:00 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 4285716A4B3 for ; Sat, 20 Sep 2003 14:12:00 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A05D843FE3 for ; Sat, 20 Sep 2003 14:11:59 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.3) with ESMTP id h8KLBxsd004036; Sat, 20 Sep 2003 14:11:59 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id h8KLBwQq004035; Sat, 20 Sep 2003 14:11:58 -0700 (PDT) (envelope-from rizzo) Date: Sat, 20 Sep 2003 14:11:58 -0700 From: Luigi Rizzo To: John Polstra Message-ID: <20030920141158.B97439@xorpc.icir.org> References: <20030920100911.B55993@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jdp@polstra.com on Sat, Sep 20, 2003 at 01:00:54PM -0700 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:12:00 -0000 On Sat, Sep 20, 2003 at 01:00:54PM -0700, John Polstra wrote: > On 20-Sep-2003 Luigi Rizzo wrote: > > > the main problem, as i see it, is that when there are PHY events you > > still need to do some expensive work while holding a lock that > > blocks interrupts, with very bad impact on the worst-case > > response of the system. > > I agree that is a problem, but I don't think it is the main problem. 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, 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. 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). cheers luigi