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.
Bruce
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
