Those weird numbers generated by rmap12a on tiobench shows that the page
replacement algorithm in rmap is not able to detect cache pollution,
that lefts pollution in cache rather than discarding the pollution, so
later that is causing reads not to be served from disk, but to be served
from cache.
Being tiobench an I/O benchmark the above is a completly fake result,
seq read I/O is not going to be faster with rmap. If you change tiobench
to remount the fs where the output files are been generated between the
"random write" and the "seq read" tests, you should get out comparable
numbers.
I don't consider goodness the fact rmap12a lefts old pollution in the
caches, that seems to proof it will do the wrong thing when the most
recently used data is part of the working set (like after you do the
first cvs checkout, you want the second checkout not to hit the disk,
this page replacement in rmap12a should hit the disk the second time
too).
In some ways tiobench has the same problems of dbench. A broken page
replacement algorithm can generate stellar numbers in both of the two
benchmarks.
Furthmore running the 'seq read' after the 'random write' (tiobench does
that), adds even more "random" to the output of the 'seq read' because
the 'random read' and 'random write' tests are not comparable in first
place too: the random seed is setup always different, and also to make a
real 'seq read' test, the 'seq read' should be run after the 'seq
write', not after the 'random write' (even assuming the random seed is
always initialized to the same value).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/