On Thu, May 17, 2007 at 07:26:38PM -0400, Bill Davidsen wrote:I have posted the results of my initial testing, measuring IPC rates using various schedulers under no load, limited nice load, and heavy load at nice 0.
http://www.tmr.com/~davidsen/ctxbench_testing.html
Kernel compiles are not how to stress these. The way to stress them is
to have multiple simultaneous independent chains of communicators and
deeper chains of communicators.
Kernel compiles are little but background cpu/memory load for these
sorts of tests.
... Something expected to have some sort of mutualThe original intent was purely to measure IPC speed under no load conditions, since fairness is in vogue I also attempted to look for surprising behavior. Corresponding values under equal load may be useful in relation to one another, but this isn't (and hopefully doesn't claim to be) a benchmark. It may or may not be useful viewed in that light, but that's not the target.
interference depending on quality of implementation would be a better
sort of competing load, one vastly more reflective of real workloads.
For instance, another set of processes communicating using the same
primitive.
Perhaps best of all would be a macrobenchmark utilizing a variety ofAnd that's a very good point, either multiple copies or more forked processes might be useful, and I do intend to add threaded tests on the next upgrade, but perhaps a whole new code might be better for generating the load you suggest.
the primitives under consideration. Unsurprisingly, major commercial
databases do so for major benchmarks.