Date: Wed, 19 Dec 2007 20:24:48 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: David G Lawrence <dg@dglawrence.com> Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds Message-ID: <20071219182448.GD57756@deviant.kiev.zoral.com.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--wULyF7TL5taEdwHz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 19, 2007 at 08:11:59PM +0200, 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 =20
> > > >almost
> > > >instantly.
> > >=20
> > > I was able to verify last night that (cd /; tar -cpf -) > all.tar wou=
ld
> > > 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.
> >=20
> > 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 th=
at
> > 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.
>=20
> 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 sle=
ep.
>=20
> I never booted with the change.
>=20
> diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c
> index cbccc62..e686b97 100644
Or, better to use uio_yield(). See below.
diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c
index cbccc62..5d2535f 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 =3D VFSTOUFS(mp);
struct fs *fs;
int error, count, wait, lockreq, allerror =3D 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);
=20
+ yield_count =3D 0;
MNT_VNODE_FOREACH(vp, mp, mvp) {
/*
* Depend on the mntvnode_slock to keep things stable enough
@@ -1233,6 +1235,12 @@ loop:
(IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) =3D=3D 0 &&
vp->v_bufobj.bo_dirty.bv_cnt =3D=3D 0)) {
VI_UNLOCK(vp);
+ if (yield_count++ =3D=3D 500) {
+ MNT_IUNLOCK(mp);
+ yield_count =3D 0;
+ uio_yield();
+ goto relock_mp;
+ }
continue;
}
MNT_IUNLOCK(mp);
@@ -1247,6 +1255,7 @@ loop:
if ((error =3D ffs_syncvnode(vp, waitfor)) !=3D 0)
allerror =3D error;
vput(vp);
+ relock_mp:
MNT_ILOCK(mp);
}
MNT_IUNLOCK(mp);
--wULyF7TL5taEdwHz
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHaWHwC3+MBN1Mb4gRArC6AJ4rYZhWlamxL8uvszTZp2sVfNACkQCgqugO
4roWpidQRMN1XzFyhqB/2f0=
=e7xk
-----END PGP SIGNATURE-----
--wULyF7TL5taEdwHz--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071219182448.GD57756>