interrupt latency and driver locking

[John Polstra]

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