[MMTests] IO metadata on XFS

[Mel Gorman <mgorman@suse.de>]

Configuration:	global-dhp__io-metadata-xfs
Benchmarks:	dbench3, fsmark-single, fsmark-threaded

Summary
=======
Most of the figures look good and in general there has been consistent good
performance from XFS. However, fsmark-single is showing a severe performance
dip in a few cases somewhere between 3.1 and 3.4. fs-mark running a single
thread took a particularly bad dive in 3.4 for two machines that is worth
examining closer. Unfortunately it is harder to easy conclusions as the
gains/losses are not consistent between machines which may be related to
the available number of CPU threads.

Benchmark notes
===============

mkfs was run on system startup.
mkfs parameters -f -d agcount=8
mount options inode64,delaylog,logbsize=262144,nobarrier for the most part.
	On kernels to old to support delaylog was removed. On kernels
	where it was the default, it was specified and the warning ignored.

dbench3 was chosen as it's metadata intensive.
  o Duration was 180 seconds
  o OSYNC, OSYNC_DIRECTORY and FSYNC were all off

  As noted in the MMTests, dbench3 can be a random number generator
  particularly when run in asynchronous mode. Even with the limitations,
  it can be useful as an early warning system and as it's still used by
  QA teams it's still worth keeping an eye on.

FSMark
  o Parallel directories were used
  o 1 Thread per CPU
  o 0 Filesize
  o 225 directories
  o 22500 files per directory
  o 50000 files per iteration
  o 15 iterations
  Single: ./fs_mark  -d  /tmp/fsmark-9227/1  -D  225  -N  22500  -n  50000  -L  15  -S0  -s  0
  Thread: ./fs_mark  -d  /tmp/fsmark-9407/1  -d  /tmp/fsmark-9407/2  -D  225  -N  22500  -n  25000  -L  15  -S0  -s  0
 
  FSMark is a more realistic indicator of metadata intensive workloads.


===========================================================
Machine:	arnold
Result:		http://www.csn.ul.ie/~mel/postings/mmtests-20120424/global-dhp__io-metadata-xfs/arnold/comparison.html
Arch:		x86
CPUs:		1 socket, 2 threads
Model:		Pentium 4
Disk:		Single Rotary Disk
Status:		Great
===========================================================

dbench
------
  XFS is showing steady improvements with a large gain for single client
  in 2.6.39 and more or less retained since then. This is also true for
  higher number of clients although 64 clients was suspiciously poor even
  though 128 clients looked better. I didn't re-examine the raw data to
  see why.

  In general, dbench is looking very good.

fsmark-single
-------------
  Again, this is looking good. Files/sec has improved slightly with the
  exception of a small dip in 3.2 and 3.3 which may be due to IO-Less
  dirty throttling.

  Overhead measurements are a bit all over the place. Not clear if
  this is cause for concern or not.

fsmark-threaded
---------------
  Improved since 2.6.32 and has been steadily good for some time. Overhead
  measurements are all over the place. Again, not clear if this is a cause
  for concern.

==========================================================
Machine:	hydra
Result:		http://www.csn.ul.ie/~mel/postings/mmtests-20120424/global-dhp__io-metadata-ext3/hydra/comparison.html
Arch:		x86-64
CPUs:		1 socket, 4 threads
Model:		AMD Phenom II X4 940
Disk:		Single Rotary Disk
Status:		Ok
==========================================================

dbench
------
  The results here look very different to the arnold machine. This is curious
  because the disks have similar size and performance characteristics. It is
  doubtful that the difference is between 32 bit and 64 bit architectures.
  The discrepency may be more due to the different number of CPUs and how
  XFS does locking. One possibility is that fewer CPUs has the side-effect
  of better batching of some operations but this is a case.

  Figures areis showing that throughput is worse and highly variable in
  3.4 for single clients. For higher number of clients figures look better
  overall. There was a dip in 3.1-based kernels though for an unknown
  reason. This does not exactly correlate with the ext3 figures although
  it showed a dip in performance at 3.2.

fsmark-single
-------------
  While performance is better than 2.6.32, there was a dip in performance
  in 3.3 and a very large dip in 3.4. 

fsmark-threaded
---------------
  The same dip in 3.4 is visibile when multiple threads are used but it is
  not as severe.

==========================================================
Machine:	sandy
Result:		http://www.csn.ul.ie/~mel/postings/mmtests-20120424/global-dhp__io-metadata-ext3/sandy/comparison.html
Arch:		x86-64
CPUs:		1 socket, 8 threads
Model:		Intel Core i7-2600
Disk:		Single Rotary Disk
Status:		Fine
==========================================================

dbench
------
 Like seen on other filesystems, this data shows that there was a large dip
 in performance around 3.2 for single threads. Unlike the hydra machine,
 this was recovered in 3.4. As higher number of threads are used the gains
 and losses are inconsistent making it hard to draw a solid conclusion.

fsmark-single
-------------
  This was doing great until 3.4 where there is a large drop.

fsmark-threaded
---------------
  Unlike the single threaded case, things are looking great here.

-- 
Mel Gorman
SUSE Labs