Date: Fri, 3 Sep 2010 21:35:50 -0500 From: "Rick C. Petty" <rick-freebsd2009@kiwi-computer.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Hannes Hauswedell <h2+freebsd@fsfe.org>, freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? Message-ID: <20100904023550.GB47730@rix.kiwi-computer.com> In-Reply-To: <2070918035.372723.1283355990476.JavaMail.root@erie.cs.uoguelph.ca> References: <201009011339.15898.h2%2Bfreebsd@fsfe.org> <2070918035.372723.1283355990476.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 01, 2010 at 11:46:30AM -0400, Rick Macklem wrote: > > > > I am experiencing similar issues with newnfs: > > > > 1) I have two clients that each get around 0.5MiB/s to 2.6MiB/s > > reading > > from the NFS4-share on Gbit-Lan > > > > 2) Mounting with -t newnfs -o nfsv3 results in no performance gain > > whatsoever. > > > > 3) Mounting with -t nfs results in 58MiB/s ! (Netcat has similar > > performance) ??? not a hardware/driver issue from my pov > > Ok, so it does sound like an issue in the experimental client and > not NFSv4. For the most part, the read code is the same as > the regular client, but it hasn't been brought up-to-date > with recent changes. Do you (or will you soon) have some patches I/we could test? I'm willing to try anything to avoid mounting ten or so subdirectories in each of my mount points. > One thing you could try is building a kernel without SMP enabled > and see if that helps? (I only have single core hardware, so I won't > see any SMP races.) If that helps, I can compare the regular vs > experimental client for smp locking in the read stuff. I can try disabling SMP too. Should that really matter, if you're not even pegging one CPU? The locks shouldn't have *that* much overhead... -- Rick C. Petty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100904023550.GB47730>