> Tue, Dec 18, 2007 at 06:20:53PM +0100, vermaden wrote:
> > > After reading this I feel that you have absolutely no packets on
> > > either interfaces when your Linux box ping FreeBSD. But this
> > > contradicts with your previous assertion that if ICMP packet comes
> > > in on rl1, then it is re
* David G Lawrence <[EMAIL PROTECTED]> [071219 09:12] 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 runn
> >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
* David G Lawrence <[EMAIL PROTECTED]> [071221 15:42] 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 tha
I'm just an observer, and I may be confused, but it seems to me that this is
motion in the wrong direction (at least, it's not going to fix the actual
problem). As I understand the problem, once you reach a certain point, the
system slows down *every* 30.999 seconds. Now, it's possible for the co
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
On Fri, Dec 21, 2007 at 05:43:09PM -0800, David Schwartz wrote:
>
>
> I'm just an observer, and I may be confused, but it seems to me that this is
> motion in the wrong direction (at least, it's not going to fix the actual
> problem). As I understand the problem, once you reach a certain point, t
On Fri, Dec 21, 2007 at 10:30:51PM -0500, Mark Fullmer wrote:
> The uio_yield() idea did not work. Still have the same 31 second
> interval packet loss.
What patch you have used ?
Lets check whether the syncer is the culprit for you.
Please, change the value of the syncdelay at the sys/kern/vfs
On Fri, Dec 21, 2007 at 04:24:32PM -0800, Alfred Perlstein wrote:
> * David G Lawrence <[EMAIL PROTECTED]> [071221 15:42] 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
>
On Dec 22, 2007, at 12:36 AM, Kostik Belousov wrote:
On Fri, Dec 21, 2007 at 10:30:51PM -0500, Mark Fullmer wrote:
The uio_yield() idea did not work. Still have the same 31 second
interval packet loss.
What patch you have used ?
This is hand applied from the diff you sent December 19, 2007
> >What patch you have used ?
>
> This is hand applied from the diff you sent December 19, 2007 1:24:48
> PM EST
Mark, try the previos patch from Kostik - the one that does the one
tick msleep. I think you'll find that that one does work. The likely
problem with the second version is that ui
On Sat, Dec 22, 2007 at 01:28:31AM -0500, Mark Fullmer wrote:
>
> On Dec 22, 2007, at 12:36 AM, Kostik Belousov wrote:
> >Lets check whether the syncer is the culprit for you.
> >Please, change the value of the syncdelay at the sys/kern/vfs_subr.c
> >around the line 238 from 30 to some other value
> I'm just an observer, and I may be confused, but it seems to me that this is
> motion in the wrong direction (at least, it's not going to fix the actual
> problem). As I understand the problem, once you reach a certain point, the
> system slows down *every* 30.999 seconds. Now, it's possible for
> As Bruce Evans noted, there is a vfs_msync() that do almost the same
> traversal of the vnodes. It was missed in the previous patch. Try this one.
I forgot to comment on that when Bruce pointed that out. My solution
has been to comment out the call to vfs_msync. :-) It comes into play
when yo
> > > 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
15 matches
Mail list logo
