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
--
