MFC NFS FHA changes 249592 and 249596:

  ------------------------------------------------------------------------
  r249592 | ken | 2013-04-17 15:00:22 -0600 (Wed, 17 Apr 2013) | 180 lines

  Revamp the old NFS server's File Handle Affinity (FHA) code so that
  it will work with either the old or new server.

  The FHA code keeps a cache of currently active file handles for
  NFSv2 and v3 requests, so that read and write requests for the same
  file are directed to the same group of threads (reads) or thread
  (writes).  It does not currently work for NFSv4 requests.  They are
  more complex, and will take more work to support.

  This improves read-ahead performance, especially with ZFS, if the
  FHA tuning parameters are configured appropriately.  Without the
  FHA code, concurrent reads that are part of a sequential read from
  a file will be directed to separate NFS threads.  This has the
  effect of confusing the ZFS zfetch (prefetch) code and makes
  sequential reads significantly slower with clients like Linux that
  do a lot of prefetching.

  The FHA code has also been updated to direct write requests to nearby
  file offsets to the same thread in the same way it batches reads,
  and the FHA code will now also send writes to multiple threads when
  needed.

  This improves sequential write performance in ZFS, because writes
  to a file are now more ordered.  Since NFS writes (generally
  less than 64K) are smaller than the typical ZFS record size
  (usually 128K), out of order NFS writes to the same block can
  trigger a read in ZFS.  Sending them down the same thread increases
  the odds of their being in order.

  In order for multiple write threads per file in the FHA code to be
  useful, writes in the NFS server have been changed to use a LK_SHARED
  vnode lock, and upgrade that to LK_EXCLUSIVE if the filesystem
  doesn't allow multiple writers to a file at once.  ZFS is currently
  the only filesystem that allows multiple writers to a file, because
  it has internal file range locking.  This change does not affect the
  NFSv4 code.

  This improves random write performance to a single file in ZFS, since
  we can now have multiple writers inside ZFS at one time.

  I have changed the default tuning parameters to a 22 bit (4MB)
  window size (from 256K) and unlimited commands per thread as a
  result of my benchmarking with ZFS.

  The FHA code has been updated to allow configuring the tuning
  parameters from loader tunable variables in addition to sysctl
  variables.  The read offset window calculation has been slightly
  modified as well.  Instead of having separate bins, each file
  handle has a rolling window of bin_shift size.  This minimizes
  glitches in throughput when shifting from one bin to another.

  sys/conf/files:
  	Add nfs_fha_new.c and nfs_fha_old.c.  Compile nfs_fha.c
  	when either the old or the new NFS server is built.

  sys/fs/nfs/nfsport.h,
  sys/fs/nfs/nfs_commonport.c:
  	Bring in changes from Rick Macklem to newnfs_realign that
  	allow it to operate in blocking (M_WAITOK) or non-blocking
  	(M_NOWAIT) mode.

  sys/fs/nfs/nfs_commonsubs.c,
  sys/fs/nfs/nfs_var.h:
  	Bring in a change from Rick Macklem to allow telling
  	nfsm_dissect() whether or not to wait for mallocs.

  sys/fs/nfs/nfsm_subs.h:
  	Bring in changes from Rick Macklem to create a new
  	nfsm_dissect_nonblock() inline function and
  	NFSM_DISSECT_NONBLOCK() macro.

  sys/fs/nfs/nfs_commonkrpc.c,
  sys/fs/nfsclient/nfs_clkrpc.c:
  	Add the malloc wait flag to a newnfs_realign() call.

  sys/fs/nfsserver/nfs_nfsdkrpc.c:
  	Setup the new NFS server's RPC thread pool so that it will
  	call the FHA code.

  	Add the malloc flag argument to newnfs_realign().

  	Unstaticize newnfs_nfsv3_procid[] so that we can use it in
  	the FHA code.

  sys/fs/nfsserver/nfs_nfsdsocket.c:
  	In nfsrvd_dorpc(), add NFSPROC_WRITE to the list of RPC types
  	that use the LK_SHARED lock type.

  sys/fs/nfsserver/nfs_nfsdport.c:
  	In nfsd_fhtovp(), if we're starting a write, check to see
  	whether the underlying filesystem supports shared writes.
  	If not, upgrade the lock type from LK_SHARED to LK_EXCLUSIVE.

  sys/nfsserver/nfs_fha.c:
  	Remove all code that is specific to the NFS server
  	implementation.  Anything that is server-specific is now
  	accessed through a callback supplied by that server's FHA
  	shim in the new softc.

  	There are now separate sysctls and tunables for the FHA
  	implementations for the old and new NFS servers.  The new
  	NFS server has its tunables under vfs.nfsd.fha, the old
  	NFS server's tunables are under vfs.nfsrv.fha as before.

  	In fha_extract_info(), use callouts for all server-specific
  	code.  Getting file handles and offsets is now done in the
  	individual server's shim module.

  	In fha_hash_entry_choose_thread(), change the way we decide
  	whether two reads are in proximity to each other.
  	Previously, the calculation was a simple shift operation to
  	see whether the offsets were in the same power of 2 bucket.
  	The issue was that there would be a bucket (and therefore
  	thread) transition, even if the reads were in close
  	proximity.  When there is a thread transition, reads wind
  	up going somewhat out of order, and ZFS gets confused.

  	The new calculation simply tries to see whether the offsets
  	are within 1 << bin_shift of each other.  If they are, the
  	reads will be sent to the same thread.

  	The effect of this change is that for sequential reads, if
  	the client doesn't exceed the max_reqs_per_nfsd parameter
  	and the bin_shift is set to a reasonable value (22, or
  	4MB works well in my tests), the reads in any sequential
  	stream will largely be confined to a single thread.

  	Change fha_assign() so that it takes a softc argument.  It
  	is now called from the individual server's shim code, which
  	will pass in the softc.

  	Change fhe_stats_sysctl() so that it takes a softc
  	parameter.  It is now called from the individual server's
  	shim code.  Add the current offset to the list of things
  	printed out about each active thread.

  	Change the num_reads and num_writes counters in the
  	fha_hash_entry structure to 32-bit values, and rename them
  	num_rw and num_exclusive, respectively, to reflect their
  	changed usage.

  	Add an enable sysctl and tunable that allows the user to
  	disable the FHA code (when vfs.XXX.fha.enable = 0).  This
  	is useful for before/after performance comparisons.

  nfs_fha.h:
  	Move most structure definitions out of nfs_fha.c and into
  	the header file, so that the individual server shims can
  	see them.

  	Change the default bin_shift to 22 (4MB) instead of 18
  	(256K).  Allow unlimited commands per thread.

  sys/nfsserver/nfs_fha_old.c,
  sys/nfsserver/nfs_fha_old.h,
  sys/fs/nfsserver/nfs_fha_new.c,
  sys/fs/nfsserver/nfs_fha_new.h:
  	Add shims for the old and new NFS servers to interface with
  	the FHA code, and callbacks for the

  	The shims contain all of the code and definitions that are
  	specific to the NFS servers.

  	They setup the server-specific callbacks and set the server
  	name for the sysctl and loader tunable variables.

  sys/nfsserver/nfs_srvkrpc.c:
  	Configure the RPC code to call fhaold_assign() instead of
  	fha_assign().

  sys/modules/nfsd/Makefile:
  	Add nfs_fha.c and nfs_fha_new.c.

  sys/modules/nfsserver/Makefile:
  	Add nfs_fha_old.c.

  Reviewed by:	rmacklem
  Sponsored by:	Spectra Logic

  ------------------------------------------------------------------------
  r249596 | ken | 2013-04-17 16:42:43 -0600 (Wed, 17 Apr 2013) | 7 lines

  Move the NFS FHA (File Handle Affinity) code from sys/nfsserver to
  sys/nfs, since it is now shared by the two NFS servers.

  Suggested by:	rmacklem
  Sponsored by:	Spectra Logic
  ------------------------------------------------------------------------

Sponsored by:	Spectra Logic


git-svn-id: svn+ssh://svn.freebsd.org/base/stable/9@251641 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
MFC r250626:

Add less to rescue build.


git-svn-id: svn+ssh://svn.freebsd.org/base/stable/9@251642 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
MFC r251431:

Pull in r183297 from upstream llvm trunk:

  PR15662: Optimized debug info produces out of order function
  parameters

  When a function is inlined we lazily construct the variables
  representing the function's parameters. After that, we add any
  remaining unused parameters.

  If the function doesn't use all the parameters, or uses them out of
  order, then the DWARF would produce them in that order, producing a
  parameter order that doesn't match the source.

  This fix causes us to always keep the arg variables at the start of
  the variable list & in the original order from the source.

Reported by:	avg


git-svn-id: svn+ssh://svn.freebsd.org/base/stable/9@251645 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f