Re: interrupt latency and driver locking

From: Sam Leffler (sam_at_errno.com)
Date: 09/22/03

  • Next message: M. Warner Losh: "Re: kobj multiple inheritance" 
    Date: Mon, 22 Sep 2003 08:50:15 -0700
To: harti@freebsd.org, "M. Warner Losh" <imp@bsdimp.com>

    > 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

    _______________________________________________
    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: M. Warner Losh: "Re: kobj multiple inheritance"

    Relevant Pages

    • Re: interrupt latency and driver locking
      ... SL>> Perhaps the polling should be configurable., I struggled with this a year ... SL>> perfect except for the MII ... SL>which drivers have been converted from spl's to mutex's. ... I'm willing to add mii locking but can't ...
      (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)