Packet loss every 30.999 seconds

Mark Fullmer maf at
Fri Dec 21 19:57:50 PST 2007

The uio_yield() idea did not work.  Still have the same 31 second  
packet loss.

Is it safe to assume the vp will be valid after a msleep() or  
uio_yield()?  If
so can we do something a little different:


/* this takes too long when list is large */
MNT_VNODE_FOREACH(vp, mp, mvp) {
  do work

Why not do this incrementally and call ffs_sync() more often, or
break it out into ffs_isync() (incremental sync).

static struct vnode *vp;

/* first? */
if (!vp)
   vp = __mnt_vnode_first(&mvp, mp);

for (vcount = 0; vp && (vcount != 500); ++vcount) {
   do work
   vp = __mnt_vnode_next(&mvp, mp);

The problem I see with this is a race condition where this list may  
between the incremental calls.


On Dec 21, 2007, at 6:43 PM, David G Lawrence wrote:

>>>    Unfortunately, the version of the patch that I sent out isn't  
>>> going to
>>> help your problem. It needs to yield at the top of the loop, but  
>>> vp isn't
>>> necessarily valid after the wakeup from the msleep. That's a  
>>> problem that
>>> I'm having trouble figuring out a solution to - the solutions  
>>> that come
>>> to mind will all significantly increase the overhead of the loop.
>> I apologize for not reading the code as I am swamped, but a technique
>> that Matt Dillon used for bufs might work here.
>> Can you use a placeholder vnode as a place to restart the scan?
>> you might have to mark it special so that other threads/things
>> (getnewvnode()?) don't molest it, but it can provide for a convenient
>> restart point.
>    That was one of the solutions that I considered and rejected  
> since it
> would significantly increase the overhead of the loop.
>    The solution provided by Kostik Belousov that uses uio_yield  
> looks like
> a find solution. I intend to try it out on some servers RSN.
> -DG
> David G. Lawrence
> President
> Download Technologies, Inc. - - (866)  
> 399 8500
> The FreeBSD Project -
> Pave the road of life with opportunities.
> _______________________________________________
> freebsd-net at mailing list
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at"

More information about the freebsd-net mailing list