Date: Tue, 23 Sep 2003 09:45:39 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Sam Leffler <sam@errno.com> Cc: jdp@polstra.com Subject: Re: interrupt latency and driver locking Message-ID: <20030923094042.B9690@beagle.fokus.fraunhofer.de> In-Reply-To: <839561335.1064220615@melange.errno.com> References: <20030920141158.B97439@xorpc.icir.org> <XFMail.20030920142934.jdp@polstra.com> <20030922160106.Y6621@beagle.fokus.fraunhofer.de> <839561335.1064220615@melange.errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Sep 2003, Sam Leffler wrote: SL>> On Sat, 20 Sep 2003, M. Warner Losh wrote: SL>> SL>> MWL>In message: <XFMail.20030920142934.jdp@polstra.com> SL>> MWL> John Polstra <jdp@polstra.com> writes: SL>> MWL>: there will be no link changes except at bootstrap and shutdown. SL>> MWL> SL>> MWL>For server machines. For laptops, these events happen more often. SL>> MWL>However, for most laptops, the rate that they happen is typically on SL>> MWL>less than 1/hour. Still rare enough to not worry about optimizing it SL>> MWL>and your other points are good. I just wanted to make sure that it SL>> MWL>wasn't optimized to the point where disconnecting the cable from the SL>> MWL>laptop to move it across the room, or another room doesn't cause huge SL>> MWL>problems. SL>> SL>> Perhaps the polling should be configurable., I struggled with this a year SL>> ago in the xl driver. I have an application that does real-time satellite SL>> simulation over two ethernet links with HZ=10000. This works really SL>> perfect (timing errors are not larger than 200usecs) except for the MII SL>> polling. With help from msilby we could cut down the mii polling delay SL>> from 8msecs to below 1msec. But, because that's still too much for my SL>> application, I have simply commented out the polling calls in the mii SL>> source. I suppose there are other application (servers) where one could SL>> simply switch them off. This could perhaps be done with a sysctl in SL>> mii(4). SL> SL>I don't believe removing functionality is the right approach (though for SL>specialized applications it might be what you have to do). I brought up SL>the issue because it is widespread and has noticeable impact on SL>performance. Some of this is a byproduct of the semi-mechanical way in SL>which drivers have been converted from spl's to mutex's. It also appears SL>some of the current work can be removed entirely for certain devices. I was not talking about removing any functionality just to make it configurable. There are just cases, where you cannot afford the 1msec or 10msec or whatever delay the polling incures. IF it is possible to overcome this by appropriate changes to the locking strategy, then this is of course the preferable solution. I can live with this stuff removed locally in my tree until a better solution is found. harti SL>I think we can move the mii bus polling/tick processing out from under the SL>driver lock so these operations do not interfere with interrupt processing. SL>But I'm not sure if this device-dependent; hence I didn't just add a lock SL>to mii and sweep the drivers. I'm willing to add mii locking but can't SL>deal with all the drivers. Before I do something in mii I'd like to SL>understand better whether it's worthwhile or whether we'll still have to SL>grab the driver lock to do the work. I suppose if I just add locking to SL>mii then those drivers that are unchanged will just incur double locking SL>until they are "fixed". -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030923094042.B9690>