Thanks. Have a kernel building now. It takes about a day of uptime
after reboot before I'll see the problem.
--
mark
On Dec 17, 2007, at 5:24 AM, David G Lawrence wrote:
While trying to diagnose a packet loss problem in a RELENG_6 snapshot
dated
November 8, 2007 it looks like I've stumbled across a broken
driver or
kernel routine which stops interrupt processing long enough to
severly
degrade network performance every 30.99 seconds.
I noticed this as well some time ago. The problem has to do with
the
processing (syncing) of vnodes. When the total number of allocated
vnodes
in the system grows to tens of thousands, the ~31 second periodic sync
process takes a long time to run. Try this patch and let people
know if
it helps your problem. It will periodically wait for one tick (1ms)
every
500 vnodes of processing, which will allow other things to run.
Index: ufs/ffs/ffs_vfsops.c
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.290.2.16
diff -c -r1.290.2.16 ffs_vfsops.c
*** ufs/ffs/ffs_vfsops.c 9 Oct 2006 19:47:17 -0000 1.290.2.16
--- ufs/ffs/ffs_vfsops.c 25 Apr 2007 01:58:15 -0000
***************
*** 1109,1114 ****
--- 1109,1115 ----
int softdep_deps;
int softdep_accdeps;
struct bufobj *bo;
+ int flushed_count = 0;
fs = ump->um_fs;
if (fs->fs_fmod != 0 && fs->fs_ronly != 0) { /* XXX */
***************
*** 1174,1179 ****
--- 1175,1184 ----
allerror = error;
vput(vp);
MNT_ILOCK(mp);
+ if (flushed_count++ > 500) {
+ flushed_count = 0;
+ msleep(&flushed_count, MNT_MTX(mp), PZERO, "syncw", 1);
+ }
}
MNT_IUNLOCK(mp);
/*
-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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"