Posted Jul 23, 2009 17:04 UTC (Thu) by jengelh (subscriber, #33263)
[Link]
Uh, extracting a tarball with lots of files and watching the %sy time is likely to do the same.
A short history of btrfs
Posted Jul 25, 2009 21:20 UTC (Sat) by bronson (subscriber, #4806)
[Link]
So, you're going to arrange some way of recording average %sy time as a single number (there are lots of different ways of doing this), then somehow graph it that makes sense to regular people?
Just timing a file decompression is a lot easier for all involved, no? It's not a great benchmark, true, but it will quickly and reliably tell you if one FS requires more CPU than another. And that's the most important thing.
The problem is not with benchmark itself...
Posted Jul 23, 2009 17:50 UTC (Thu) by khim (subscriber, #9252)
[Link]
Uh, having the cpu loaded will find problems if the FS code
itself is too cpu hoggy....
The problem is not with low-level CPU bound benchmark but with average
taken from many different benchmarks without a case or thought. In the end
you are getting average temperature of hospice patients: some are having
high
fever, some are in morgue already, so in the end average temperature is
useless.
If you plan to mix a lot of different benchmarks you must be ready to
carefully study the results, separate expected results from unexpected
ones,
cluster them in groups (by relevance to this or that real-word task), etc.
Ortherwise it's just pointless race where winner is more-or-less
random.
And it's also pointless to try to fix the situation by adding more
benchmarks to the mix: when you mix a lot of differend kinds of food - you
are getting pile of garbage as a result and if you'll add some more dishes
- you'll just get a bigger pile of garbage.