Date: Mon, 22 Sep 2003 08:50:15 -0700 From: Sam Leffler <sam@errno.com> To: harti@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Cc: jdp@polstra.com Subject: Re: interrupt latency and driver locking Message-ID: <839561335.1064220615@melange.errno.com> In-Reply-To: <20030922160106.Y6621@beagle.fokus.fraunhofer.de> References: <20030920141158.B97439@xorpc.icir.org> <XFMail.20030920142934.jdp@polstra.com> <20030920.214835.101559646.imp@bsdimp.com> <20030922160106.Y6621@beagle.fokus.fraunhofer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sat, 20 Sep 2003, M. Warner Losh wrote: > > MWL>In message: <XFMail.20030920142934.jdp@polstra.com> > MWL> John Polstra <jdp@polstra.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?839561335.1064220615>