I'm sorry, but all you are doing with these tests is discrediting
lmbench, AIM9, tiobench and unixbench. There really is nothing in
these patches which can account for the changes which you are observing.
Possibly, it is all caused by cache colouring effects - the physical
addresses at which critical kernel and userspace text and data
happen to end up.
I'd suggest that you look for more complex tests. There's a decent
list at http://lbs.sourceforge.net/, but even those are rather microscopic.
If you have time, things like the osdl dbt1 test, http://osdb.sourceforge.net/
and the commercial benchmarks would be more interesting.
Or cook up some of your own: it's not hard. Just think of some time-consuming
operation which we perform on a daily basis and measure it. Script
the startup and shutdown of X11 applications. rsync. sendmail. cvs.
Mixed workloads are interesting and real world: run tiobench or dbench
or qsbench or whatever while trying to do something else, see how long
"something else" takes.
It is these sorts of things which will find areas of weakness which
can be addressed in this phase of kernel development.
The teeny little microbenchmarks are telling us that the rmap overhead
hurts, that the uninlining of copy_*_user may have been a bad idea, that
the addition of AIO has cost a little and that the complexity which
yielded large improvements in readv(), writev() and SMP throughput were
not free. All of this is already known.
-
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/