Re: [BENCHMARK] 2.6.3-rc2 v 2.6.3-rc3-mm1 kernbench

[bill davidsen]

In article <200402170130.24070.kernel@xxxxxxxxxxx>,
Con Kolivas  <kernel@xxxxxxxxxxx> 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@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/