From: Bill Davidsen <davidsen@tmr.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Linux Kernel mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Scheduling tests on IPC methods, fc6, sd0.48, cfs12
Date: Tue, 22 May 2007 18:36:30 -0400 [thread overview]
Message-ID: <4653706E.80702@tmr.com> (raw)
In-Reply-To: <20070521093958.GI19966@holomorphy.com>
William Lee Irwin III wrote:
> 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.
Just so. What is being quantified is the rate of slowdown due to
external load. I would hope that each IPC method would slow by some
similar factor.
> ... Something expected to have some sort of mutual
> 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.
>
The 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.
> Perhaps best of all would be a macrobenchmark utilizing a variety of
> the primitives under consideration. Unsurprisingly, major commercial
> databases do so for major benchmarks.
>
And 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.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
prev parent reply other threads:[~2007-05-22 22:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-17 23:26 Scheduling tests on IPC methods, fc6, sd0.48, cfs12 Bill Davidsen
2007-05-21 7:30 ` Ingo Molnar
2007-05-22 22:23 ` Bill Davidsen
2007-05-21 9:39 ` William Lee Irwin III
2007-05-22 22:36 ` Bill Davidsen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4653706E.80702@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox