In lmbench2, getppid() is used for a null syscall, the average of
read one int from /dev/zero and write one int to /dev/null is used
for null I/O.
Moving on....
With respect to the tired old claims that lmbench isn't predictive of real
world performance, I wish people would reread either the benchmark or
the paper, or both, and then think a little before flaming. Or better
yet, produce something better. Flaming is easy but it is basically
masturbation without the orgasm so why bother?
The benchmark measures things which have been known to be performance
problems in the past. That will not predict how /well/ future
applications will perform. It will not predict how /well/ any
applications will perform.
The only thing that predicts application performance is the application.
What lmbench will do, and the reason that it is popular, is tell you how
your OS vs. somebody else's OS does on a bunch of interesting things.
While having good numbers most certainly does not result in good
application performance, having bad numbers frequently does result in
bad application performance. The reason for that is that the things
that lmbench measures have been repeatedly shown to be important to a
large range of applications.
Try a stereo analogy. Most people understand that if you screw up any
part of your stereo, be it speakers, amp, CD player, speaker wire,
whatever, then the whole thing sounds like shit. Think of lmbench
as measuring speakers, amp and CD but missing speaker wire and tuner.
Having good lmbench numbers does not mean you have a good stereo, it means
you have the potential to have a good stereo but you need to fill in the
missing chunks yourself. On the other hand, having bad lmbench numbers
means that your stereo cant's sound good until you fix those numbers.
I can't wait to see a quote out of context:
"Larry McVoy has finally completely lost it,
claims bad lmbench numbers lead to bad stereo performance"
:-)
All that said, new applications can arise which have critical performance
paths that are not measured by lmbench. To the extent that it is
possible, I'm interested in measuring that stuff so if you have a specific
thing you want measured, send me mail and I'll try and whip something up.
Please note that I won't include benchmarks that are portable across Unix
systems - no Linux specific stuff, no Solaris, no SGI, just generic stuff.
Also note that there is nothing stopping you from grabbing a benchmark that
is close to what you want, modifying it to do what you want, and creating
a new benchmark by throwing away the rest of the stuff in lmbench. I'm
sort of disappointed that people don't do that. The timing harness in
lmbench2alpha is really cool and makes it easy to do easy things. For
example, the null syscall test is:
#include "bench.h"
main()
{
BENCH(getppid(), 0);
micro("Simple syscall", get_n());
}
It doesn't get any easier than that, folks. If you want your tests to
be include in lmbench, send them to me. If you want to create a new
test, don't call it lmbench (though you are welcome to note that it uses
the lmbench timing harness). I don't want people to get confused about
what lmbench is and isn't, there seems to be enough confusion as it is.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html