public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

      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