redhat 7.3 an PE 2650 indicate 4 Processors instead 2

Khan Khan
Wed Dec 18 13:13:00 CST 2002

> Message: 2
> Date: Wed, 18 Dec 2002 23:16:29 +1000 (EST)
> From: jason andrade <jason at>
> To: Shahram <shahram at>
> cc: Amit_Bhutani at, <linux-poweredge at>
> Subject: Re: redhat 7.3 an PE 2650 indicate 4 Processors instead 2
> On Wed, 18 Dec 2002, Shahram wrote:
> > is this advantageous to run with Hyper-Threading on Redhat 7.3?
> hyperthreading should give you an extra 25-40% of available 
> cpu depending
> on the application (multithreaded ? multiple applications?).
> > is there any disadvantage known?
> there hasn't been any feedback which talks about disadvantages at this
> point but it is still a relatively new piece of technology in terms of
> widespread deployment.  i am sure they will crop up.
> there have been a couple of reports of people solving some stability
> issues by disabling hyperthreading but they have not been conclusive.

In our particular application (PE 2650 dual 2.4Ghz), hyperthreaded
processing was substantially slower than when we disabled hyperthreading.

With hyperthreading enabled, our particular application (integer log
processing) took as much as 85% longer than single CPU processing.

As a rough benchmark, it took roughly 52 min/GB to process the logs with
hyperthreading (two processes), and it took 41 min/GB to process the logs
with just one CPU.

After we disabled hyperthreading, and re-enabled dual processing, we got
down to 28 min/GB.

If we normalize the single-CPU result, then we get:

1.26		Dual Proc (two processes), Hyperthreading (4 cpus)
1		Single Proc (one process), Hyperthreading (4 cpus)
0.68		Dual Proc (two processes), No-Hyperthreading, (2 cpus)

If I did my math right, this means that dual processing with hyperthreading
off takes almost half (46%) as long as dual processing with hyperthreading
on, and our application benefitted by approximately 32% by dual processing.

I can't speak to the underlying issue as to why this occurs, but I am
confident that disabling hyperthreading in a single process pass would have
turned in similar results to the single process hyperthreading
configuration... In other words, the problem is made worse the more the OS
attempts to use hyperthreading.

In this case, we're talking about Red Hat 7.3. I recommend, if you are not
seeing the results you anticipated, testing with hyperthreading off to
validate that it provides a performance boost to your particular application
under a variety of loads; HT definitely has the potential to be a
significant disadvantage.

More information about the Linux-PowerEdge mailing list