[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
interrupt latency and driver locking
- Subject: interrupt latency and driver locking
- From: rizzo at icir.org (Luigi Rizzo)
- Date: Sat Sep 20 10:09:53 2003
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.
> 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
> freebsd-arch_(_at_)_freebsd_(_dot_)_org mailing list
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe_(_at_)_freebsd_(_dot_)_org"