Hi,
I've put up the full set of RPC changes that I'd like to push into 2.4.20 in
http://www.fys.uio.no/~trondmy/src/2.4.19-pre10/linux-2.4.19-RPC_ALL.dif
The full set of partial patches can be found in the same directory.
Patches contain
1) Full set of 2.5.x kmap() changes for avoiding highmem deadlocks.
2) RTT (round trip timing) estimation for improving the UDP timeout + resend
mechanism. Algorithm is the standard one as described in the Van Jacobson
paper (see http://www-nrg.ee.lbl.gov/papers/congavoid.pdf)
3) Slow start + congestion avoidance algorithms for UDP. Again see the Van
Jacobson paper.
4) A couple of minor cleanups.
In particular, it would be nice if people could test out the RTT + congestion
avoidance. Although it is probably not a cure for all of our UDP problems, I
would expect performance to improve on most platforms. In particular, I'd
very much encourage those people who reported a performance slowdown with the
previous NFS_ALL patch to test this out.
Cheers,
Trond
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
hi trond-
i'm able to deadlock my dual 1.26GHz P-III with just these patches applied
to a naked 2.4.19-pre10 kernel:
linux-2.4.19-00-fix_refresh.dif
linux-2.4.19-01-fix_kmap1.dif
linux-2.4.19-02-fix_kmap2.dif
linux-2.4.19-03-fix_kmap3.dif
i'm running "make -j2 bzImage" with other minor activity in the same file
system (editing files, building small packages). the file system is
stored on a NetApp filer.
i was using 19-pre8-NFSALL on other slower systems without trouble, but
i think 19-pre8-NFSALL may have had some trouble on this system too.
pre8, pre9, and pre10 work without problem on this system. fix_refresh
alone appeared to work OK on this system.
On Fri, 21 Jun 2002, Trond Myklebust wrote:
>
> Hi,
>
> I've put up the full set of RPC changes that I'd like to push into 2.4.20 in
>
> http://www.fys.uio.no/~trondmy/src/2.4.19-pre10/linux-2.4.19-RPC_ALL.dif
>
> The full set of partial patches can be found in the same directory.
>
> Patches contain
>
> 1) Full set of 2.5.x kmap() changes for avoiding highmem deadlocks.
>
> 2) RTT (round trip timing) estimation for improving the UDP timeout + resend
> mechanism. Algorithm is the standard one as described in the Van Jacobson
> paper (see http://www-nrg.ee.lbl.gov/papers/congavoid.pdf)
>
> 3) Slow start + congestion avoidance algorithms for UDP. Again see the Van
> Jacobson paper.
>
> 4) A couple of minor cleanups.
>
> In particular, it would be nice if people could test out the RTT + congestion
> avoidance. Although it is probably not a cure for all of our UDP problems, I
> would expect performance to improve on most platforms. In particular, I'd
> very much encourage those people who reported a performance slowdown with the
> previous NFS_ALL patch to test this out.
>
> Cheers,
> Trond
>
- Chuck Lever
--
corporate: <[email protected]>
personal: <[email protected]>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Saturday 29 June 2002 20:53, Chuck Lever wrote:
> hi trond-
>
> i'm able to deadlock my dual 1.26GHz P-III with just these patches applied
> to a naked 2.4.19-pre10 kernel:
>
> linux-2.4.19-00-fix_refresh.dif
> linux-2.4.19-01-fix_kmap1.dif
> linux-2.4.19-02-fix_kmap2.dif
> linux-2.4.19-03-fix_kmap3.dif
Any chance of finding out which one of the 3 kmap patches is the one giving
trouble?
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
> On Saturday 29 June 2002 20:53, Chuck Lever wrote:
> > i'm able to deadlock my dual 1.26GHz P-III with just these
> patches applied
> > to a naked 2.4.19-pre10 kernel:
> >
> > linux-2.4.19-00-fix_refresh.dif
> > linux-2.4.19-01-fix_kmap1.dif
> > linux-2.4.19-02-fix_kmap2.dif
> > linux-2.4.19-03-fix_kmap3.dif
>
> Any chance of finding out which one of the 3 kmap patches is
> the one giving trouble?
yes. fix_refresh + fix_kmap1 hangs under stress on my system.
i can reproduce this with "make -j2 bzImage" in one window
and "bonnie" in a loop in another. both cwd's are in the
same TCP-mounted NFS file system.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tuesday 02 July 2002 19:59, Lever, Charles wrote:
> yes. fix_refresh + fix_kmap1 hangs under stress on my system.
>
> i can reproduce this with "make -j2 bzImage" in one window
> and "bonnie" in a loop in another. both cwd's are in the
> same TCP-mounted NFS file system.
Is this with CONFIG_HIGHMEM set (you didn't specify your .config) and does it
only happen on TCP mounts? If so, then the appended bugfix might help...
Cheers,
Trond
> On Tuesday 02 July 2002 19:59, Lever, Charles wrote:
>
> > yes. fix_refresh + fix_kmap1 hangs under stress on my system.
> >
> > i can reproduce this with "make -j2 bzImage" in one window
> > and "bonnie" in a loop in another. both cwd's are in the
> > same TCP-mounted NFS file system.
>
> Is this with CONFIG_HIGHMEM set (you didn't specify your
> .config) and does it only happen on TCP mounts?
my bad... yes, this is a 1GB system, so HIGHMEM is set, and
yes, the file system is a TCP file system.
> If so, then the appended bugfix might help...
i tested today against 2.4.19-rc1 with fix-kmap1 applied.
it appeared to have the previously attached fix in it
already.
i was not able to deadlock my system.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Oh, it's good to be a geek.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs