From: Samuel Flory <sflory@rackable.com>
To: mcuss@cdlsystems.com
Cc: jamesclv@us.ibm.com, root@chaos.analogic.com,
linux-kernel@vger.kernel.org
Subject: Re: Kernel reports 4 CPUS instead of 2...
Date: Wed, 16 Oct 2002 13:47:32 -0700 [thread overview]
Message-ID: <3DADD064.8010707@rackable.com> (raw)
In-Reply-To: 0d3901c2754c$7bf17060$2c0e10ac@frinkiac7
Mark Cuss wrote:
>Speaking of performance.... :)
>
>Has anyone done any testing on a dual CPU configuration like this? I've
>been testing this box with both the RedHat 8 Stock Kernel (2.4.18.something)
>and 2.4.19 from kernel.org. Currently, I can't make the thing perform
>anywhere near as fast as my Dual PIII 1 Ghz box (running 2.4.7 for the last
>325 days...) . I've been compiling the same block of code on both the
>machines and comparing the times. The PIII box is around 7 s, while the new
>Xeon Box is 13 or 14s...
>
>My thinking was that since the CPUs are much faster, and the FSB is faster,
>and the disk controller is faster, that the computer would be faster.
>
>The hardware is obviously faster, I'm sure its just something I've done
>wrong in the kernel configuration... If anyone has any advice or words of
>wisdom, I'd really appreciate them...
>
>
Try shutting off hyperthreading in the bios. Keep in mind
hyperthreading is net loss if you are running a single nonthreaded app.
Also you might want to check if there aren't io speed issues.
A good way to see the effects positive effects of hyperthreading is a
kernel compile. A "make -j 4 bzImage" should be much much faster on the
Xeon system with hyperthreading than a P3.
>
>Mark
>
>----- Original Message -----
>From: "James Cleverdon" <jamesclv@us.ibm.com>
>To: <root@chaos.analogic.com>; "Samuel Flory" <sflory@rackable.com>
>Cc: "Mark Cuss" <mcuss@cdlsystems.com>; <linux-kernel@vger.kernel.org>
>Sent: Wednesday, October 16, 2002 1:28 PM
>Subject: Re: Kernel reports 4 CPUS instead of 2...
>
>
>
>
>>On Wednesday 16 October 2002 10:54 am, Richard B. Johnson wrote:
>>
>>
>>>On Wed, 16 Oct 2002, Samuel Flory wrote:
>>>
>>>
>>>>>On Wed, 16 Oct 2002, Mark Cuss wrote:
>>>>>
>>>>>This is the correct behavior. If you don't like this, you can
>>>>>swap motherboards with me ;) Otherwise, grin and bear it!
>>>>>
>>>>>
>>>> Wouldn't it be easier just to turn off the hypertreading or jackson
>>>>tech option in the bios ;-)
>>>>
>>>>
>>>Why would you ever want to turn it off? You paid for a CPU with
>>>two execution units and you want to disable one? This makes
>>>no sense unless you are using Windows/2000/Professional, which
>>>will trash your disks and all their files if you have two
>>>or more CPUs (true).
>>>
>>>
>>No, you're thinking of IBM's Power4 chip, which really does have two CPU
>>
>>
>cores
>
>
>>on one chip, sharing only the L2 cache.
>>
>>The P4 hyperthreading shares just about all CPU resources between the two
>>threads of execution. There are only separate registers, local APIC, and
>>some other minor logic for each "CPU" to call its own. All execution
>>
>>
>units
>
>
>>are demand shared between them. (The new "pause" opcode, rep nop, allows
>>
>>
>one
>
>
>>half to yield resources to the other half.)
>>
>>That's why typical job mixes only get around 20% improvement. Even
>>
>>
>optimized
>
>
>>benchmarks, which run only integer code on one side and floating point on
>>
>>
>the
>
>
>>other only get around a 40% boost. The P4 just doesn't have all that many
>>execution units to go around. Future chips will probably do better.
>>
>>
>>
>>>Cheers,
>>>Dick Johnson
>>>Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
>>>The US military has given us many words, FUBAR, SNAFU, now ENRON.
>>>Yes, top management were graduates of West Point and Annapolis.
>>>
>>>
>>--
>>James Cleverdon
>>IBM xSeries Linux Solutions
>>{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>>
>
>
>
>
next prev parent reply other threads:[~2002-10-16 20:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-16 17:24 Kernel reports 4 CPUS instead of 2 Mark Cuss
2002-10-16 17:35 ` Richard B. Johnson
2002-10-16 17:56 ` Samuel Flory
2002-10-16 17:54 ` Richard B. Johnson
2002-10-16 18:14 ` Samuel Flory
2002-10-16 19:28 ` James Cleverdon
2002-10-16 19:44 ` Mark Cuss
2002-10-16 20:10 ` Richard B. Johnson
2002-10-16 20:47 ` Samuel Flory [this message]
2002-10-16 21:44 ` Mark Mielke
2002-10-16 22:14 ` Samuel Flory
2002-10-16 22:21 ` Mark Cuss
2002-10-16 18:37 ` Mark Cuss
2002-10-16 23:21 ` Bryan Whitehead
2002-10-17 0:34 ` Mark Chernault
2002-10-17 12:56 ` Richard B. Johnson
2002-10-17 14:19 ` Dave Jones
2002-10-17 17:15 ` Bryan B Whitehead
2002-10-16 17:37 ` Joel Jaeggli
2002-10-16 17:48 ` Mark Cuss
2002-10-16 17:44 ` FD Cami
-- strict thread matches above, loose matches on Subject: below --
2002-10-16 18:08 Nakajima, Jun
2002-10-17 1:02 Matt_Domsch
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=3DADD064.8010707@rackable.com \
--to=sflory@rackable.com \
--cc=jamesclv@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcuss@cdlsystems.com \
--cc=root@chaos.analogic.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.