Packet loss every 30.999 seconds

Bruce Evans brde at
Wed Dec 19 08:49:52 PST 2007

On Wed, 19 Dec 2007, David G Lawrence wrote:

>> Debugging shows that the problem is like I said.  The loop really does
>> take 125 ns per iteration.  This time is actually not very much.  The
>   Considering that the CPU clock cycle time is on the order of 300ps, I
> would say 125ns to do a few checks is pathetic.

As I said, 125 nsec is a short time in this context.  It is approximately
the time for a single L2 cache miss on a machine with slow memory like
freefall (Xeon 2.8 GHz with L2 cache latency of 155.5 ns).  As I said,
the code is organized so as to give about 4 L2 cache misses per vnode
if there are more than a few thousand vnodes, so it is doing very well
to take only 125 nsec for a few checks.

>   In any case, it appears that my patch is a no-op, at least for the
> problem I was trying to solve. This has me confused, however, because at
> one point the problem was mitigated with it. The patch has gone through
> several iterations, however, and it could be that it was made to the top
> of the loop, before any of the checks, in a previous version. Hmmm.

The patch should work fine.  IIRC, it yields voluntarily so that other
things can run.  I committed a similar hack for uiomove().  It was
easy to make syscalls that take many seconds (now tenths of seconds
insted of seconds?), and without yielding or PREEMPTION or multiple
CPUs, everything except interrupts has to wait for these syscalls.  Now
the main problem is to figure out why PREEMPTION doesn't work.  I'm
not working on this directly since I'm running ~5.2 where nearly-full
kernel preemption doesn't work due to Giant locking.


More information about the freebsd-net mailing list