Re: PATCH [NFSd] NFSv3/TCP

Re: PATCH [NFSd] NFSv3/TCP

[Greg Banks]

Neil Brown wrote:
> 
> There was once a patch floating around which allowed a larger
> NFSSVC_MAXBLKSIZE on architectures with large page sizes, but it never
> got properly submitted I think.

Then please consider this a resend.  I'll appreciate any guidance
about proper submission.

This patch has been in SGI's ProPack kernel for 6 months and resulted
in a significant improvement in NFS throughput at a number of customer
sites.

--- /usr/tmp/TmpDir.16250-0/linux/linux/include/linux/nfsd/const.h_1.5	Fri May  7
17:20:22 2004
+++ /usr/tmp/TmpDir.16250-0/linux/linux/include/linux/nfsd/const.h	Fri May  7
17:20:22 2004
@@ -12,6 +12,7 @@
 #include <linux/nfs.h>
 #include <linux/nfs2.h>
 #include <linux/nfs3.h>
+#include <asm/page.h>
 
 /*
  * Maximum protocol version supported by knfsd
@@ -19,9 +20,16 @@
 #define NFSSVC_MAXVERS		3
 
 /*
- * Maximum blocksize supported by daemon currently at 8K
+ * Maximum blocksize supported by daemon.  We want the largest
+ * value which 1) fits in a UDP datagram less some headers
+ * 2) is a multiple of page size 3) can be successfully kmalloc()ed
+ * by each nfsd.   
  */
-#define NFSSVC_MAXBLKSIZE	(8*1024)
+#if PAGE_SIZE > (16*1024)
+#define NFSSVC_MAXBLKSIZE	(32*1024)
+#else
+#define NFSSVC_MAXBLKSIZE	(2*PAGE_SIZE)
+#endif
 
 #ifdef __KERNEL__
 


Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.

Re: PATCH [NFSd] NFSv3/TCP

[Oliver Tennert]

As it does not any changes for say a i386 architecture, I cannot see why
after that my lockups should go away.

Are lockups no known problem at all? Am I the only one experiencing them?
They _definitely_ went away for me with NFSSVC_MAXBLKSIZE equal 32k, even
under high IO pressure.

Regards

Oliver


On Fri, 7 May 2004, Greg Banks wrote:

>
> Then please consider this a resend.  I'll appreciate any guidance
> about proper submission.
>
> This patch has been in SGI's ProPack kernel for 6 months and resulted
> in a significant improvement in NFS throughput at a number of customer
> sites.
>
> --- /usr/tmp/TmpDir.16250-0/linux/linux/include/linux/nfsd/const.h_1.5	Fri May  7
> 17:20:22 2004
> +++ /usr/tmp/TmpDir.16250-0/linux/linux/include/linux/nfsd/const.h	Fri May  7
> 17:20:22 2004
> @@ -12,6 +12,7 @@
>  #include <linux/nfs.h>
>  #include <linux/nfs2.h>
>  #include <linux/nfs3.h>
> +#include <asm/page.h>
>
>  /*
>   * Maximum protocol version supported by knfsd
> @@ -19,9 +20,16 @@
>  #define NFSSVC_MAXVERS		3
>
>  /*
> - * Maximum blocksize supported by daemon currently at 8K
> + * Maximum blocksize supported by daemon.  We want the largest
> + * value which 1) fits in a UDP datagram less some headers
> + * 2) is a multiple of page size 3) can be successfully kmalloc()ed
> + * by each nfsd.
>   */
> -#define NFSSVC_MAXBLKSIZE	(8*1024)
> +#if PAGE_SIZE > (16*1024)
> +#define NFSSVC_MAXBLKSIZE	(32*1024)
> +#else
> +#define NFSSVC_MAXBLKSIZE	(2*PAGE_SIZE)
> +#endif
>
>  #ifdef __KERNEL__
>
>
>
> Greg.
> --
> Greg Banks, R&D Software Engineer, SGI Australian Software Group.
> I don't speak for SGI.
>

__
________________________________________creating IT solutions

Dr. Oliver Tennert			science + computing ag
phone   +49(0)7071 9457-598		Hagellocher Weg 71-75
fax     +49(0)7071 9457-411		D-72070 Tuebingen, Germany
O.Tennert@science-computing.de		www.science-computing.de

Re: PATCH [NFSd] NFSv3/TCP

[Greg Banks]

Oliver Tennert wrote:
> 
> As it does not any changes for say a i386 architecture, 

Yes, by design.

> I cannot see why
> after that my lockups should go away.

I don't claim any such thing,  I was just resending a patch (which is of no
use to you) that Neil mentioned had been lost in the shuffle.

> Are lockups no known problem at all? Am I the only one experiencing them?
> They _definitely_ went away for me with NFSSVC_MAXBLKSIZE equal 32k, even
> under high IO pressure.

Sure, I believe you, I just have no idea what your problem is.

As a general statement of no particular import, I note that going to 32K
has a number of other side effects other than the obvious.  For streaming
reads and writes the call rate goes down by a factor of 4 so you may be
not exercising some race condition.  Also there may be different code paths
through READDIR and READDIR+ code.

Now if you had some kind of kernel debugger and could post some more
information, like process list and kernel stack traces from the hang,
someone (not me) may be able to figure out the real problem that you've
hidden by going to 32K.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs