Recent HAMMER SMP performance work

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    A bunch of recent work has been committed which improves HAMMER's
    SMP cached read() performance and its writing/flushing disk
    performance.  Blogbench performance is just about doubled, with
    concurrent reading and writing in stage 1 operating at nearly full
    speed.

    * Previously when the buffer cache is unavailable HAMMER was getting
      its per-mount lock before calling getblk() which is capable of
      reconstituting a buffer from the VM page cache.

      This was changed to not acquire the per-mount lock, drastically
      improving concurrent cached read performance for data sets which
      exceed the size of the buffer cache but still fit in the VM page
      cache.

      For example, my x86-64 test box has 8G of ram but the buffer cache
      only maintains 1GB worth of buffers.  This greatly improves concurrent
      read performance when operating from the nearly 8G worth of VM page
      cache past the 1GB of buffer cache.  So it is a fairly big deal.

    * HAMMER accumulates enough dirty buffers, sometimes 100MB+ worth,
      that just reeling them out to the disk drive unsorted is non-optimal
      for the drive.  HAMMER now sorts the buffers which improves flush
      performance.

    * And, finally, when operating on a large number of dirty files HAMMER
      was not breaking the files into neat sets in the flush groups.  This
      has been addressed and results in inodes being freed up at a more
      consistent rate, reducing stalls when doing tar extractions, cpdup,
      etc.

      The inode reclamation pipeline has also been revisited and tuned up.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>