From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 02:35:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9D8610656A7 for ; Sat, 4 Sep 2010 02:35:51 +0000 (UTC) (envelope-from rick@rix.kiwi-computer.com) Received: from rix.kiwi-computer.com (66-191-70-202.static.stcd.mn.charter.com [66.191.70.202]) by mx1.freebsd.org (Postfix) with SMTP id 605508FC08 for ; Sat, 4 Sep 2010 02:35:51 +0000 (UTC) Received: (qmail 47979 invoked by uid 2000); 4 Sep 2010 02:35:50 -0000 Date: Fri, 3 Sep 2010 21:35:50 -0500 From: "Rick C. Petty" To: Rick Macklem Message-ID: <20100904023550.GB47730@rix.kiwi-computer.com> References: <201009011339.15898.h2+freebsd@fsfe.org> <2070918035.372723.1283355990476.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2070918035.372723.1283355990476.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: Hannes Hauswedell , freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2010 02:35:51 -0000 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