Date: Wed, 29 Jan 2014 22:22:22 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Garrett Wollman <wollman@bimajority.org> Cc: freebsd-net@freebsd.org Subject: Re: Terrible NFS performance under 9.2-RELEASE? Message-ID: <1315174039.18735121.1391052142869.JavaMail.root@uoguelph.ca> In-Reply-To: <21225.49699.916951.881502@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman wrote:
> <<On Wed, 29 Jan 2014 18:01:43 -0500 (EST), Rick Macklem
> <rmacklem@uoguelph.ca> said:
>
> > However, I do suspect we'll be putting a refined version of the
> > patch
> > in head someday (maybe April, sooner would have to be committed by
> > someone else). I suspect that Garrett's code for server read will
> > work
> > well and I'll cobble something to-gether for server readdir and
> > client write.
>
> Once I can get this mps(4) issue ironed out, I should be in a
> position
> to get some real data on this.
>
If you can check the network device driver you use and if it looks
like it has a scatter size of less than 36 (often a constant with
"TXSEG" or "TX_SEG" in the name) and calls either m_defrag() or
m_collapse(), adding a counter to see if those functions are being
called, would be nice.
If the m_collapse()/m_defrag() function is being called without
the patch and not with the patch, the performance difference may
be avoiding that call and not a more generic benefit.
I just did a quick find/grep and it looks like a lot of drivers
have *TXSEGS* set to around 32 and then call one of two functions
for more than that. Since without a patch, 64K NFS reads/writes
hand sosend() an mbuf list of 34 entries, it seems like this could
be happening a lot. (I didn't look to see which ones set if_hw_tsomax
to significantly less than 64K.)
Thanks for working on this, rick.
ps: you might want to combine your patch with mine, so readdir and
client side writes use 4K clusters.
> -GAWollman
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1315174039.18735121.1391052142869.JavaMail.root>