Note that "dropping" was meant to be more generic than just dropping a
packet. We can decide to drop packets proactively by just deciding to
disable the interface completely for a while, to make sure it doesn't
flood us with interrupts. That's obviously fairly extreme, but it might be
the simplest answer (the driver could even decide on its own to disable
itself if it sees overlong backlog queues, as long as we'd have some way
of enabling it again when the queue empties - by a timer or something).
> I pretty much concur. Except that skipping clock ticks is a Bad Thing. I
> don't mind dropping packets or characters, but if Xclock is wrong then I'm
> later for meetings than I intended to be ;->
If we do indeed skip clock-ticks, the only thing that should be able to
make that happen is somebody holding an interrupt lock for too damned
long. MUCH too long. Unrealistically long, in fact.
I don't think that's the case, I think it's the other bh routines being
starved or something, so that while the clock is being updated, timers
nerver occur because they occur in bottom half entries too (and are thus
shut out if net_bh() runs forever).
So the real-time clock should be ok unless the CPU really is spending all
its time in the network interrupt handler (as opposed to net_bh()). And
that in turn implies either a bad network driver or just that the network
is so fast that we can't even receive the packets in time, much less
actually process them..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/