public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: davidsen@tmr.com (bill davidsen)
To: linux-kernel@vger.kernel.org
Subject: Re: [BENCHMARK] 2.6.3-rc2 v 2.6.3-rc3-mm1 kernbench
Date: 17 Feb 2004 00:42:25 GMT	[thread overview]
Message-ID: <c0ro1h$48t$1@gatekeeper.tmr.com> (raw)
In-Reply-To: 200402170130.24070.kernel@kolivas.org

In article <200402170130.24070.kernel@kolivas.org>,
Con Kolivas  <kernel@kolivas.org> wrote:
| On Tue, 17 Feb 2004 00:20, Nick Piggin wrote:

| >
| > Thanks Con,
| > Results look pretty good. The half-load context switches are
| > increased - that is probably a result of active balancing.
| > And speaking of active balancing, it is not yet working across
| > nodes with the configuration you're on.
| >
| > To get some idea of our worst case SMT performance (-j8), would
| > it be possible to do -j8 and -j64 runs with HT turned off?
| 
| sure.

Now, I have a problem with the numbers here, either I don't understand
them (likely) or I don't believe them (also possible).
| 
| results.2.6.3-rc3-mm1 + SMT:
| Average Half Load Run:
| Elapsed Time 113.008
| User Time 742.786
| System Time 90.65
| Percent CPU 738
| Context Switches 28062.6
| Sleeps 24571.8


| 2.6.3-rc3-mm1 no SMT:
| Average Half Load Run:
| Elapsed Time 133.51
| User Time 799.268
| System Time 92.784
| Percent CPU 669
| Context Switches 19340.8
| Sleeps 24427.4

As I look at these numbers, I see that with SMT the real time is lower,
the system time is higher, and the system time is higher. All what I
would expect since effectively the system has twice as many CPUs.

But the user time, there I have a problem understanding. User time is
time in the user program, and I would expect user time to go up, since
resource contention inside a CPU is likely to mean less work being done
per unit of time, and therefore if you measure CPU time from the outside
you need more of it to get the job done.

And what do you get running on one non-SMT CPU for the same mix? When I
run stuff I usually see the user CPU go up a tad and the e.t. go down a
little (SMT) or quite a bit (SMP).

I have faith in the reporting of the numbers, but I wonder about the way
the data were measured. Hopefully someone can clarify, because it looks
a little like what you would see if you counted "one" for one tick worth
of user mode time in the CPU, regardless of whether one or two threads
were executing.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

  reply	other threads:[~2004-02-17  0:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-16 12:59 [BENCHMARK] 2.6.3-rc2 v 2.6.3-rc3-mm1 kernbench Con Kolivas
2004-02-16 13:20 ` Nick Piggin
2004-02-16 14:30   ` Con Kolivas
2004-02-17  0:42     ` bill davidsen [this message]
2004-02-17  4:22       ` Nick Piggin
2004-02-17 16:19         ` Bill Davidsen
2004-02-17 16:45           ` Nick Piggin
2004-02-18  0:25             ` Con Kolivas

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='c0ro1h$48t$1@gatekeeper.tmr.com' \
    --to=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.org \
    /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