Re: [RFC][PATCH 0/3] Skip I/O merges when disabled

["Alan D. Brunelle" <Alan.Brunelle@hp.com>]

Here are the results, the last kernel (2.6.25-nomerges.nofrontmerges)
had 10 runs of 2 minutes each (as opposed to 25 runs of 10 minutes each
for the other kernels). I'm doing a full run of that kernel w/
25x10minutes, but wanted to get this out for feedback first:

Increasing the merge attempts decreases the I/Os per second by less than
0.5%.

Kernel                         NM   I/Os per sec
-----------------------------  --   ------------
2.6.25                                    472.39

2.6.25-nomerges                 0         472.54
2.6.25-nomerges.onehit          0         472.10
2.6.25-nomerges.nofrontmerges   0         470.38

2.6.25-nomerges                 1         472.58
2.6.25-nomerges.onehit          1         472.02
2.6.25-nomerges.nofrontmerges   1         470.65

The savings in cycles for these random loads compared to the total cycle
costs goes from 4.4% up to 4.8% as we add in more merge attempts (as
compared to almost 5.8% for the stock 2.6.25 kernel).

Kernel                         NM  TAG   Total     I/O Code
-----------------------------  --  ----  --------  --------
2.6.25                             CPU:   5.7794%   7.5440%

2.6.25-nomerges                 0  CPU:   5.4957%   7.1987%
2.6.25-nomerges.onehit          0  CPU:   5.7822%   7.5034%
2.6.25-nomerges.nofrontmerges   0  CPU:   5.2041%   6.8534%

2.6.25-nomerges                 1  CPU:   4.4031%   5.7710%
2.6.25-nomerges.onehit          1  CPU:   4.7517%   6.1702%
2.6.25-nomerges.nofrontmerges   1  CPU:   4.8372%   6.3642%


Kernel                         NM  TAG   Total     I/O Code
-----------------------------  --  ----  --------  --------
2.6.25                             DCM:   7.9861%  10.2456%

2.6.25-nomerges                 0  DCM:   8.2134%  10.5145%
2.6.25-nomerges.onehit          0  DCM:   7.5559%   9.7389%
2.6.25-nomerges.nofrontmerges   0  DCM:   7.6436%   9.8934%

2.6.25-nomerges                 1  DCM:   6.6705%   8.5247%
2.6.25-nomerges.onehit          1  DCM:   6.3432%   8.1886%
2.6.25-nomerges.nofrontmerges   1  DCM:   7.2244%   9.3407%


Given that the tunable is meant to be turned on when the admin /knows/
the load is going to be random, it seems to me that adding in the other
merge checks (one-hit, back-merge) are going to be wasted the vast
majority of the time.

Thanks,
Alan