Messages in this thread | | | Subject | Re: [BENCHMARK] Lmbench 2.5.54-mm2 (impressive improvements) | From | "David S. Miller" <> | Date | 03 Jan 2003 02:24:37 -0800 |
| |
On Fri, 2003-01-03 at 01:33, Andrew Morton wrote: > I'm sorry, but all you are doing with these tests is discrediting > lmbench, AIM9, tiobench and unixbench. ... > 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. ... > 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.
I think if anything, you are stating the true value of the microbenchmarks. They are showing us how the kernel is getting more and more complex, causing basic operations to take longer and longer. That's bad. :-)
Last time I brought up an issue like this (a "nobody but weirdos use feature which is costing us cycles everywhere"), it got redone until it did cost nothing for people who don't use the feature. See the whole security layer fiasco for example.
I truly wish I could config out AIO for example, the overhead is just stupid. I know that if some thought is put into it, the cost could be consumed completely.
People who don't see the true value of researching even minor jitters in lmbench results (and fixing the causes or backing out the guilty patch) aren't kernel developers in my opinion. :-)
- 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/
| |