lkml.org 
[lkml]   [1998]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: NFS read performance ugliness
Date
> > Use 2.0.x. The 2.1.x NFS code needs several major modifications before it will
> > perform acceptably against Sun equipment - notably write gathering support.
> >
> > Alan
> >
> Before I proceed, I must mention that 2.0.x kernels are mostly even
> worse than 2.1.x (I tried many times in last year or two). Biggest
> write speed I got is 50KB/sec, and I remember that at misterious
> occasions I could achieve cca 200KB/sec with 2.1.x (in some older
> revision).

With 8K blocks you should be seeing well over 50K/second, some of it
is hidden by the asynchronous writeback in 2.1.x. The real problem
is that NFS is synchronous write, and Sun machines use 8K blocks on
the disk (the BSD derived UFS/vm stuff requires page sized blocks), A half
page synchronous write is incredibly machine expensive.

Because 2.1.x uses the page cache to generate requests it never generates
requests over 4K in size, even if r/wsize is set higher (unless you are
running on an 8K page host...)


> sign is offset. So we can easily see that Sun stacks 32768 bytes worth
> of data. Everything is cool.

Yep

> Strange is that packet order is reversed (in time) if I read dumps

[itsa performance trick]

> correctly. First last fragment is received, then middle one, and in
> the end, fragment that contains NFS (IP,UDP?) headers. Could this be a
> bug in Linux NFS implementation?

No

> Also, I notice, no matter what rsize, wsize options I use, dump always
> looks like that. Something like rsize,wsize=4096 is hardcoded and
> can't be changed?

Yes, thats one of the remaining NFS problems, its constrained at 4K because
it doesnt write gather

Alan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.052 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site