interrupt latency and driver locking

[Harti Brandt]

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 at polstra.com>
SL>> MWL>            John Polstra <jdp at 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 at fokus.fraunhofer.de, harti at freebsd.org