From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 08:50: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 098BD16A4B3; Mon, 22 Sep 2003 08:50:36 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DFDB43F3F; Mon, 22 Sep 2003 08:50:33 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h8MFoG0x029598 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 22 Sep 2003 08:50:19 -0700 (PDT) (envelope-from sam@errno.com) Date: Mon, 22 Sep 2003 08:50:15 -0700 From: Sam Leffler To: harti@freebsd.org, "M. Warner Losh" Message-ID: <839561335.1064220615@melange.errno.com> In-Reply-To: <20030922160106.Y6621@beagle.fokus.fraunhofer.de> References: <20030920141158.B97439@xorpc.icir.org> <20030920.214835.101559646.imp@bsdimp.com> <20030922160106.Y6621@beagle.fokus.fraunhofer.de> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: freebsd-arch@freebsd.org cc: jdp@polstra.com 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: Mon, 22 Sep 2003 15:50:36 -0000 > On Sat, 20 Sep 2003, M. Warner Losh wrote: > > MWL>In message: > MWL> John Polstra writes: > MWL>: there will be no link changes except at bootstrap and shutdown. > MWL> > MWL>For server machines. For laptops, these events happen more often. > MWL>However, for most laptops, the rate that they happen is typically on > MWL>less than 1/hour. Still rare enough to not worry about optimizing it > MWL>and your other points are good. I just wanted to make sure that it > MWL>wasn't optimized to the point where disconnecting the cable from the > MWL>laptop to move it across the room, or another room doesn't cause huge > MWL>problems. > > Perhaps the polling should be configurable., I struggled with this a year > ago in the xl driver. I have an application that does real-time satellite > simulation over two ethernet links with HZ=10000. This works really > perfect (timing errors are not larger than 200usecs) except for the MII > polling. With help from msilby we could cut down the mii polling delay > from 8msecs to below 1msec. But, because that's still too much for my > application, I have simply commented out the polling calls in the mii > source. I suppose there are other application (servers) where one could > simply switch them off. This could perhaps be done with a sysctl in > mii(4). I don't believe removing functionality is the right approach (though for specialized applications it might be what you have to do). I brought up the issue because it is widespread and has noticeable impact on performance. Some of this is a byproduct of the semi-mechanical way in which drivers have been converted from spl's to mutex's. It also appears some of the current work can be removed entirely for certain devices. I think we can move the mii bus polling/tick processing out from under the driver lock so these operations do not interfere with interrupt processing. But I'm not sure if this device-dependent; hence I didn't just add a lock to mii and sweep the drivers. I'm willing to add mii locking but can't deal with all the drivers. Before I do something in mii I'd like to understand better whether it's worthwhile or whether we'll still have to grab the driver lock to do the work. I suppose if I just add locking to mii then those drivers that are unchanged will just incur double locking until they are "fixed". Sam