Date: Thu, 20 Dec 2007 15:45:35 -0500 From: Mark Fullmer <maf@eng.oar.net> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, David G Lawrence <dg@dglawrence.com> Subject: Re: Packet loss every 30.999 seconds Message-ID: <1C1F9DB7-1B79-4718-9A27-379D1E6F0F10@eng.oar.net> In-Reply-To: <20071219181158.GC57756@deviant.kiev.zoral.com.ua> 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> <20071219181158.GC57756@deviant.kiev.zoral.com.ua>
index | next in thread | previous in thread | raw e-mail
Thanks, I'll test this later on today.
On Dec 19, 2007, at 1:11 PM, Kostik Belousov wrote:
> On Wed, Dec 19, 2007 at 09:13:31AM -0800, David G Lawrence wrote:
>>>> Try it with "find / -type f >/dev/null" to duplicate the problem
>>>> almost
>>>> instantly.
>>>
>>> I was able to verify last night that (cd /; tar -cpf -) > all.tar
>>> would
>>> trigger the problem. I'm working getting a test running with
>>> David's ffs_sync() workaround now, adding a few counters there
>>> should
>>> get this narrowed down a little more.
>>
>> 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.
>> As a very inadequate work-around, you might consider lowering
>> kern.maxvnodes to something like 20000 - that might be low enough to
>> not trigger the problem, but also be high enough to not significantly
>> affect system I/O performance.
>
> I think the following may be safe. It counts only the clean scanned
> vnodes
> and does not evaluate the vp, that indeed may be reclaimed, after
> the sleep.
>
> I never booted with the change.
>
> diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c
> index cbccc62..e686b97 100644
> --- a/sys/ufs/ffs/ffs_vfsops.c
> +++ b/sys/ufs/ffs/ffs_vfsops.c
> @@ -1176,6 +1176,7 @@ ffs_sync(mp, waitfor, td)
> struct ufsmount *ump = VFSTOUFS(mp);
> struct fs *fs;
> int error, count, wait, lockreq, allerror = 0;
> + int yield_count;
> int suspend;
> int suspended;
> int secondary_writes;
> @@ -1216,6 +1217,7 @@ loop:
> softdep_get_depcounts(mp, &softdep_deps, &softdep_accdeps);
> MNT_ILOCK(mp);
>
> + yield_count = 0;
> MNT_VNODE_FOREACH(vp, mp, mvp) {
> /*
> * Depend on the mntvnode_slock to keep things stable enough
> @@ -1233,6 +1235,11 @@ loop:
> (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 &&
> vp->v_bufobj.bo_dirty.bv_cnt == 0)) {
> VI_UNLOCK(vp);
> + if (yield_count++ == 500) {
> + yield_count = 0;
> + msleep(&yield_count, MNT_MTX(mp), PZERO,
> + "ffspause", 1);
> + }
> continue;
> }
> MNT_IUNLOCK(mp);
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1C1F9DB7-1B79-4718-9A27-379D1E6F0F10>