Re: interrupt latency and driver locking

From: John Polstra (jdp_at_polstra.com)
Date: 09/20/03

  • Next message: M. Warner Losh: "Re: interrupt latency and driver locking" 
    Date: Sat, 20 Sep 2003 14:29:34 -0700 (PDT)
To: Luigi Rizzo <rizzo@icir.org>

    On 20-Sep-2003 Luigi Rizzo wrote:
    >
    > what i mean is that i don't think the frequency of these events (once per
    > second or lower) is a big issue, but it is the fact that
    > when they hit they delay potentially urgent activities for
    > possibly very long times.
    > In fact, the 50..300us measured by Sam are not even the worst case;
    > I am pretty sure that when you have an actual PHY change the
    > delays involved can be much longer,

    I think we are basically in agreement that this needs to be fixed and
    that it will involve a separate lock. I care less about actual link
    changes than I do about the polling, because in a typical stable setup
    there will be no link changes except at bootstrap and shutdown.

    > e.g. if you do an 'ifconfig'
    > involving a media change (or even the initial 'up'), the "em" driver
    > does a busy wait of well above 1 second while in the interrupt
    > to wait for the autoconfig to settle (with DEVICE_POLLING this
    > hits you badly). Several other drivers have similar issues.

    Yes, the em driver is especially nasty in this regard. I think maybe
    changing the #define of WAIT_FOR_AUTO_NEG_DEFAULT to 0 in "if_em.h"
    would fix it, but I haven't tried that.

    > This is why i advocate a design change so that non-real-time,
    > time-consuming activities are run under a different lock
    > that does not block other real-time activities (for other
    > subsystems of course).

    Yep, me too.

    John
    _______________________________________________
    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: interrupt latency and driver locking"