Yes, but not for benchmarks. It has value only as a stability test - while
it may in some cases provide some general indication of performance, its
variance is far too large, even under controlled conditions, for it to have
any value as a benchmark. I'm surprised you'd even suggest this.
Andrea, please, if we want good benchmarks let's at least be clear on what
tools benchmarkers should/should not be using.
> the only problem with
> dbench is that you can trivially cheat and change the kernel in a broken
> way, but optimal _only_ for dbench, just to get stellar dbench numbers,
No, this is not the only problem. DBench is just plain *flaky*. You don't
appear to be clear on why. In short, dbench has two main flaws:
- It's extremely sensitive to scheduling. If one process happens to make
progress then it gets more heavily cached and its progress becomes even
greater. The benchmark completes much more quickly in this case, whereas
if all processes progress at nearly the same rate (by chance) it runs
- It can happen (again by chance) that dbench files get deleted while still
in cache, and this process completes in a fraction of the time that real
disk IO would require.
I've seen successsive runs of dbench *under identical conditions* (that is,
from a clean reboot etc.) vary by as much as 30%. Others report even greater
variance. Can we please agree that dbench is useless for benchmarks?
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/