Maxime Henrion wrote:
> Julian Elischer wrote:
> > Gleb Smirnoff wrote:
> > >On Thu, Dec 13, 2007 at 10:33:25AM -0800, Julian Elischer wrote:
> > >J> Maxime Henrion wrote:
> > >J> > Replying to myself on this one, sorry about that.
> > >J> > I said in my previous mail that I didn't know yet what p
Dear all,
It is rapidly becoming clear that quite a few of us have Big Plans for the TCP
implementation over the next 12-18 months. It's important that we get the
plans out on the table now so that everyone working on these projects is aware
of the larger context. This will encourage collab
On Tue, 18 Dec 2007, David G Lawrence wrote:
I got an almost identical delay (with 64000 vnodes).
Now, 17ms isn't much.
Says you. On modern systems, trying to run a pseudo real-time application
on an otherwise quiescent system, 17ms is just short of an eternity. I agree
that the syncer sho
On Tue, 18 Dec 2007, Mark Fullmer wrote:
A little progress.
I have a machine with a KTR enabled kernel running.
Another machine is running David's ffs_vfsops.c's patch.
I left two other machines (GENERIC kernels) running the packet loss test
overnight. At ~ 32480 seconds of uptime the proble
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 reflected at
> On Tue, 18 Dec 2007, David G Lawrence wrote:
>
> >>>I got an almost identical delay (with 64000 vnodes).
> >>>
> >>>Now, 17ms isn't much.
> >>
> >> Says you. On modern systems, trying to run a pseudo real-time
> >> application
> >>on an otherwise quiescent system, 17ms is just short of an e
> Try it with "find / -type f >/dev/null" to duplicate the problem almost
> instantly.
FreeBSD used to have some code that would cause vnodes with no cached
pages to be recycled quickly (which would have made a simple find
ineffective without reading the files at least a little bit). I guess
th
>In any case, it appears that my patch is a no-op, at least for the
> problem I was trying to solve. This has me confused, however, because at
> one point the problem was mitigated with it. The patch has gone through
> several iterations, however, and it could be that it was made to the top
> o
Hi Robert,
Comments inline.
Robert Watson wrote:
Dear all,
It is rapidly becoming clear that quite a few of us have Big Plans for
the TCP implementation over the next 12-18 months. It's important
that we get the plans out on the table now so that everyone working on
these projects is awar
David G Lawrence wrote:
Try it with "find / -type f >/dev/null" to duplicate the problem almost
instantly.
FreeBSD used to have some code that would cause vnodes with no cached
pages to be recycled quickly (which would have made a simple find
ineffective without reading the files at lea
On Wed, 19 Dec 2007, David G Lawrence wrote:
Debugging shows that the problem is like I said. The loop really does
take 125 ns per iteration. This time is actually not very much. The
Considering that the CPU clock cycle time is on the order of 300ps, I
would say 125ns to do a few checks i
> > In any case, it appears that my patch is a no-op, at least for the
> >problem I was trying to solve. This has me confused, however, because at
> >one point the problem was mitigated with it. The patch has gone through
> >several iterations, however, and it could be that it was made to the top
On Dec 19, 2007, at 9:54 AM, Bruce Evans wrote:
On Tue, 18 Dec 2007, Mark Fullmer wrote:
A little progress.
I have a machine with a KTR enabled kernel running.
Another machine is running David's ffs_vfsops.c's patch.
I left two other machines (GENERIC kernels) running the packet
loss tes
> >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
On Wed, 19 Dec 2007, David G Lawrence wrote:
Try it with "find / -type f >/dev/null" to duplicate the problem almost
instantly.
FreeBSD used to have some code that would cause vnodes with no cached
pages to be recycled quickly (which would have made a simple find
ineffective without reading
On Thu, 20 Dec 2007, Bruce Evans wrote:
On Wed, 19 Dec 2007, David G Lawrence wrote:
Considering that the CPU clock cycle time is on the order of 300ps, I
would say 125ns to do a few checks is pathetic.
As I said, 125 nsec is a short time in this context. It is approximately
the time for a
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
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
> > > >almost
> > > >instantly.
> > >
> > > I was able to verify last night that (cd /; tar
Just to confirm the patch did not change the behavior. I ran with it
last night and double checked this morning to make sure.
It looks like if you put the check at the top of the loop and the
next node
is changed during msleep() SLIST_NEXT will walk into the trash. I'm
in over my head here..
Maxime Henrion wrote:
It appears that this patch fixed the problem. My gateway server
now has a nearly two days uptime, whereas previously it would have
probably crashed already. I'm attaching the final version of the
patch here, since the last one had build-time errors. I'm going
to commit
On Wed, 19 Dec 2007, David G Lawrence wrote:
The patch should work fine. IIRC, it yields voluntarily so that other
things can run. I committed a similar hack for uiomove(). It was
It patches the bottom of the loop, which is only reached if the vnode
is dirty. So it will only help if there
David G Lawrence wrote:
In any case, it appears that my patch is a no-op, at least for the
problem I was trying to solve. This has me confused, however, because at
one point the problem was mitigated with it. The patch has gone through
several iterations, however, and it could be that it was mad
Julian Elischer wrote:
Maxime Henrion wrote:
It appears that this patch fixed the problem. My gateway server
now has a nearly two days uptime, whereas previously it would have
probably crashed already. I'm attaching the final version of the
patch here, since the last one had build-time erro
Stephen Clark wrote:
Julian Elischer wrote:
Maxime Henrion wrote:
It appears that this patch fixed the problem. My gateway server
now has a nearly two days uptime, whereas previously it would have
probably crashed already. I'm attaching the final version of the
patch here, since the last o
On Wed, Dec 19, 2007 at 11:44:00AM -0800, Julian Elischer wrote:
> David G Lawrence wrote:
> >>> In any case, it appears that my patch is a no-op, at least for the
> >>>problem I was trying to solve. This has me confused, however, because at
> >>>one point the problem was mitigated with it. The pat
Synopsis: [bge] [patch] bge has checksum problems on the 5703 chipset
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: remko
Responsible-Changed-When: Thu Dec 20 07:32:58 UTC 2007
Responsible-Changed-Why:
This seems like something for -net
http://www.freebsd.org/cgi
26 matches
Mail list logo
