Re: interrupt latency and driver locking

From: Harti Brandt (brandt_at_fokus.fraunhofer.de)
Date: 09/23/03

  • Next message: Doug Rabson: "Re: kobj multiple inheritance" 
    Date: Tue, 23 Sep 2003 09:45:39 +0200 (CEST)
To: Sam Leffler <sam@errno.com>

    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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Doug Rabson: "Re: kobj multiple inheritance"

    Relevant Pages

    • Re: interrupt latency and driver locking
      ... For laptops, ... > Perhaps the polling should be configurable., I struggled with this a year ... With help from msilby we could cut down the mii polling delay ... which drivers have been converted from spl's to mutex's. ...
      (freebsd-arch)
    • Re: Better polling solution in wince driver
      ... I am new to wince and was just worried whether the Sleep() function would ... polling in wince 5.0 drivers. ... Henrik Viklund wrote: ...
      (microsoft.public.windowsce.platbuilder)
    • Re: [PATCH v4] introduce macro spin_event_timeout()
      ... shouldn't be encouraging this kind of polling by making it very easy to ... This code doesn't even have a timeout! ... Ironically, in the situations where there is a timeout, the drivers use ...
      (Linux-Kernel)
    • Re: better leve triggered IRQ management needed
      ... (or heck, if things are this broken, you probably want it for all ... That is really something drivers should handle themselves if they are doing ... They didn't *want* edge trigger ... polling once per second is better than not polling at tall there.,.. ...
      (Linux-Kernel)
    • Quantcast