Re: interrupt latency and driver locking

From: Luigi Rizzo (rizzo_at_icir.org)
Date: 09/20/03

  • Next message: John Polstra: "Re: interrupt latency and driver locking" 
    Date: Sat, 20 Sep 2003 10:09:11 -0700
To: John Polstra <jdp@polstra.com>

    On Sat, Sep 20, 2003 at 09:48:20AM -0700, John Polstra wrote:
    ...
    > > Note that the fxp driver holds its driver lock for an average 112 us in one
    > > spot. This turns out to be in fxp_tick and the likely culprit is the call
    > > to mii_tick which is done with the lock held.
    >
    > Agreed. The MII calls usually have lots of DELAY() calls in them.
    >
    > > I'm not sure if it's simple to move MII operations outside of the driver
    > > lock but it might be worth investigating.
    >
    > It seems like it ought to be possible to at least lock at a finer
    > grain for those calls. The driver lock is held because the MII

    the main problem, as i see it, is that when there are PHY events you
    still need to do some expensive work while holding a lock that
    blocks interrupts, with very bad impact on the worst-case
    response of the system.

    One option in these cases could be to do the following:
     1. disable the offending device while doing the expensive work
        (e.g. reconfigure the PHY);
     2. acquire a different lock (lock2) on the device;
     3. release the lock that prevents (other) interrupts to be delivered
     4. do the thing, hoever long it takes
     5. re-enable the device
     6. release the lock2

    this would work fine for PHY events because the interface is
    presumably not in a state to process traffic anyways, so disabling
    it should have no bad side effects;
    maybe other drivers (e.g. parallel ports, or devices where you have
    to do bit-banging to move data without too many timing constraints)
    could use a similar approach.

            cheers
            luigi

    > routines call back into the driver and use it to do the bit-twiddling
    > necessary to shift data into and out of the PHY registers via the
    > PHY's serial interface. That's normally pretty independent of
    > anything else that's going on in the chip, so it could probably be
    > done under a separate lock.
    >
    > Another idea would be to substitute something else for DELAY() calls
    > of more than a few microseconds. I am not very up-to-date on -current
    > these days, but as far as I know DELAY() is still a spin-wait. If
    > the delay is for more than a few microseconds it would probably be
    > better to switch to a different runnable thread and come back later.
    > In fact, CPU speeds may have reached the point where that is always
    > the right thing to do.
    >
    > Finally, the entire mii_tick() nonsense could be thrown out for many
    > modern network adapters. Both the Broadcom and Intel gigabit chips
    > are capable of interrupting on interesting link events, so there is no
    > need at all to poll the PHY every second. That doesn't appear to be
    > true of the fxp devices, though. They need to be polled. Still, you
    > can avoid the expensive PHY reads and writes most of the time. For
    > example, if you have received any packets on the interface in the past
    > second, you can assume that link is good and never touch the PHY at
    > all.
    >
    > 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"
    _______________________________________________
    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: John Polstra: "Re: interrupt latency and driver locking"

    Relevant Pages

    • RE: interrupt latency and driver locking
      ... The machine had an fxp device on one side and an em on ... > to mii_tick which is done with the lock held. ... The MII calls usually have lots of DELAY() calls in them. ... need at all to poll the PHY every second. ...
      (freebsd-arch)
    • Re: Possible circular locking dependency while running valgrind on an executable over CIFS
      ... But it would seem impractical to delay sending read requests from ... readpages - seems to defeat the whole purpose of having a higher ... drivers, various network file systems, some cluster file systems) ... running 2.6.25 with a few of the debug options enabled, including lock ...
      (Linux-Kernel)
    • Re: [patch] increase spinlock-debug looping timeouts from 1 sec to 1 min
      ... Being on the edge of an NMI watchdog induced system crash ... Pretty much the only thing the loop condition ... I'm assuming that the additional delay in the debug code has worsened the ... I get that impression;) If it takes 1-2 seconds to get this lock then it ...
      (Linux-Kernel)
    • Re: Invoking UI from woker thread.
      ... The delay here is to slow down the process because the script process must ... Perhaps a 200 millisecons should do ... I don't understand why should I implement a lock mechanism here? ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Delay Generators in FPGAs
      ... you can sweep from min to max input ... The DLL is fussier, as it chooses to arrange its six delay lines based ... and lose lock. ...
      (comp.arch.fpga)