From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 16:24:40 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 DCBE010656D1 for ; Sat, 4 Sep 2010 16:24:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 973FB8FC0C for ; Sat, 4 Sep 2010 16:24:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAPYPgkyDaFvO/2dsb2JhbACDF5BdjhmpRZEihEl0BIoX X-IronPort-AV: E=Sophos;i="4.56,318,1280721600"; d="scan'208";a="92829093" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 04 Sep 2010 12:24:38 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E37DBB3F29; Sat, 4 Sep 2010 12:24:38 -0400 (EDT) Date: Sat, 4 Sep 2010 12:24:38 -0400 (EDT) From: Rick Macklem To: rick-freebsd2009@kiwi-computer.com Message-ID: <987774370.493418.1283617478821.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100904023550.GB47730@rix.kiwi-computer.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_493417_877221575.1283617478819" X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) 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 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 16:24:40 -0000 ------=_Part_493417_877221575.1283617478819 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > > 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. > Attached is a small patch for the only difference I can spot in the read code between the regular and experimental NFS client. I have asked jhb@ to try and do some testing, to see if he can reproduce it. If he does reproduce it, maybe he can figure out what is going on. (I don't think I'll have any further patches to try, unless he spots something.) > > 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 > If running UMP fixes the problem, it is most likely a missing lock that allows a race to put things in a weird state. But for these things, it is often something I'd never expect that turns out to be the culprit. rick ------=_Part_493417_877221575.1283617478819 Content-Type: text/x-patch; name=nfsclbio.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=nfsclbio.patch LS0tIGZzL25mc2NsaWVudC9uZnNfY2xiaW8uYy5zYXYJMjAxMC0wOS0wNCAxMDo0NjowNi4wMDAw MDAwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2xiaW8uYwkyMDEwLTA5LTA0IDEwOjQ3 OjA2LjAwMDAwMDAwMCAtMDQwMApAQCAtNTEwLDEwICs1MTAsNyBAQAogCQkJICAgIHJhYnAgPSBu ZnNfZ2V0Y2FjaGVibGsodnAsIHJhYm4sIGJpb3NpemUsIHRkKTsKIAkJCSAgICBpZiAoIXJhYnAp IHsKIAkJCQllcnJvciA9IG5ld25mc19zaWdpbnRyKG5tcCwgdGQpOwotCQkJCWlmIChlcnJvcikK LQkJCQkgICAgcmV0dXJuIChlcnJvcik7Ci0JCQkJZWxzZQotCQkJCSAgICBicmVhazsKKwkJCQly ZXR1cm4gKGVycm9yID8gZXJyb3IgOiBFSU5UUik7CiAJCQkgICAgfQogCQkJICAgIGlmICgocmFi cC0+Yl9mbGFncyAmIChCX0NBQ0hFfEJfREVMV1JJKSkgPT0gMCkgewogCQkJCXJhYnAtPmJfZmxh Z3MgfD0gQl9BU1lOQzsK ------=_Part_493417_877221575.1283617478819--