Date: Fri, 16 Apr 2010 18:36:07 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: arch@FreeBSD.org, Andriy Gapon <avg@FreeBSD.org> Subject: Re: (in)appropriate uses for MAXBSIZE Message-ID: <20100416181926.F1082@delplex.bde.org> In-Reply-To: <Pine.GSO.4.63.1004142234200.28565@muncher.cs.uoguelph.ca> References: <4BBEE2DD.3090409@freebsd.org> <Pine.GSO.4.63.1004090941200.14439@muncher.cs.uoguelph.ca> <4BBF3C5A.7040009@freebsd.org> <20100411114405.L10562@delplex.bde.org> <Pine.GSO.4.63.1004110946400.27203@muncher.cs.uoguelph.ca> <20100414135230.U12587@delplex.bde.org> <Pine.GSO.4.63.1004142234200.28565@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Apr 2010, Rick Macklem wrote: > On Wed, 14 Apr 2010, Bruce Evans wrote: > [stuff snipped] >> >> Indeed, I was only caring about a LAN environment. Especially with >> LANs optimized for latency (50-100 uS), nfs performance is poor for >> small files, at least for the old nfs client, mainly due to close to >> open consistency defeating caching, but not a problem for bulk transfers. > > And I'll admit I was thinking that for a low latency LAN, a large read/write > RPC wouldn't have a negative impact, but it sounds like > you've found 16Kb to be optimal for this case. I'll try to find old benchmark results or repeat the benchmarks. > For NFSv4, if the client has a delegation for the file, it doesn't > have worry about close/open consistency, so there is some hope w.r.t. > small files for this case. Do you have benchmarks? A kernel build (without -j) is a good test. Due to include bloat and include nesting bloat, a kernel build opens and closes the same small include files hundreds or thousands of times each, with O(10^5) includes altogether, so an RPC to read attributes on each open costs a lot of latency. nfs on a LAN does well to take only 10% longer than a local file system on a LAN and after disabling close/open constency takes only about half as much longer, by reducing the nomber of RPCs by about a factor of 2. The difference should be even more noticable on a WAN. Building with -j reduces the extra length by not stalling the whild build waiting for each RPC. I probably needed it to take only 10% longer. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100416181926.F1082>