Date: Fri, 21 Dec 2007 22:30:51 -0500 From: Mark Fullmer <maf@splintered.net> To: David G Lawrence <dg@dglawrence.com> Cc: freebsd-net@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds Message-ID: <6D374B4C-0D98-4916-A762-7A85912B3058@splintered.net> In-Reply-To: <20071221234347.GS25053@tnn.dglawrence.com> References: <D50B5BA8-5A80-4370-8F20-6B3A531C2E9B@eng.oar.net> <20071217102433.GQ25053@tnn.dglawrence.com> <CD187AD1-8712-418F-9F49-FA3407BA1AC7@eng.oar.net> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The uio_yield() idea did not work. Still have the same 31 second
interval
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:
Currently:
/* 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
change
between the incremental calls.
--
mark
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. - http://www.downloadtech.com - (866)
> 399 8500
> The FreeBSD Project - http://www.freebsd.org
> Pave the road of life with opportunities.
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6D374B4C-0D98-4916-A762-7A85912B3058>