Bug 147823 - FEAT: RHEL3 U6: Enable dual-core processors from Intel
FEAT: RHEL3 U6: Enable dual-core processors from Intel
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jim Paradis
IT_65113, IT_67605
: FutureFeature
Depends On:
Blocks: 156321
  Show dependency treegraph
Reported: 2005-02-11 13:08 EST by Issue Tracker
Modified: 2013-08-05 21:12 EDT (History)
3 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 10:46:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Issue Tracker 2005-02-11 13:08:21 EST
Escalated to Bugzilla from IssueTracker
Comment 5 Larry Troan 2005-02-11 13:14:31 EST
We're past the cutoff for new RHEL3 U5 features and have no Intel dual-core
hardware. If we can get the hardware and verify the cores work with no or very
minor hits, then we can support. Otherwise, suspect this will be U2 support.
Comment 11 Larry Troan 2005-02-23 11:02:01 EST
From Keve at Intel:
The current distribuitions don't have the support for identifying cores
that may be present on physical package.  Currently all the logical
processors on the same package will appear as siblings.  So, if a CPU
package has 2 cores and each core is HT enabled then /proc/cpuinfo will
show 4 siblings.

When we add the multi-core detection support [which is still not committed for
RHEL3], kernel will be able to identify each core seperately.  So, for the
example above, user aplications will be able to find out 2 logical execution
units is sitting on which core.  The number of siblings will still be 4.

Thanks, rohit
Comment 12 Larry Troan 2005-02-25 14:37:55 EST
rpc error - hand pasting this entry here fro Issue Tracker
 Event posted 02-25-2005 12:59pm by Daryl with duration of 0.00 	
 Send this event to Bugzilla ID:  147823  (Sent 02/25/2005 14:36)
Hardware (Smithfield) arrived at RH this morning for inclusion in xw4300
prototype.    Was delayed by need for 3-way SITR between us and Intel.

Setting to "Waiting on Tech" since you now have hardware.

Status set to: Waiting on Tech 
Comment 13 Larry Troan 2005-03-04 11:14:01 EST
The expectation is that Intel dual-cores will work with no changes to RHEL4 U1,
making them appear as one processor with multiple siblings.

Proof is in the testing.
Comment 14 Larry Troan 2005-04-07 08:14:11 EDT
Correction to comment #13 above:

For RHEL4U1/RHEL3U5, the Intel dual cores require HT turned off in the BIOS.
They will then appear as two (SMP) processors w/o HT. Intel tells us that if HT
is enabled, the machine will run very slowly... and customers WILL notice.

Intel has a patch for RHEL4U2/RHEL3U6 that will allow HT to be enabled and that
will take full advantage of the enhanced U1 scheduler.
Comment 15 Geoff Gustafson 2005-04-28 10:57:53 EDT
Let me clarify for the record -- it definitely doesn't _require_ turning off HT
in the BIOS. It depends on the workload whether or not that would improve or
hurt overall performance.

Intel has definitely never indicated that "if HT is enabled, the machine will
run very slowly". :) It's just that with the scheduling unaware of the true
machine structure, it _may_ schedule things poorly. Basically, say two
CPU-intensive threads are running. The scheduler has a 1 in 3 chance of
scheduling them on the same core, in which case they will be competing for the
same execution resources. Depending on the exact instruction sequences, this
will result in a 0-100% slowdown over what would be achieved on separate cores.

But again, that only happens 1/3rd of the time (and this is just the case of two
threads running). The other 2/3rd of the time there is no such problem. And when
there are three or more threads running, actual HT benefits will be observed
that generally make performance better than a simple 2p SMP w/ no HT. So it's
something of a wash, and the main annoyance is just non-deterministic
performance. Compile a kernel three times and it will take different amounts of
time. The proposed improvements will allow the scheduler to work properly and
eliminate the worst-case behaviors, so the sooner they get in, the better.
Comment 16 Jim Paradis 2005-05-11 13:41:33 EDT
The major issue here is one of CPU enumeration.  The RHEL3 scheduler is
HT-aware, and it does active load balancing to ensure that loads are spread out
among physical CPUs.  For this to work properly, we need to ensure that each
physical core is separately enumerated and that HT siblings are correctly
enumerated among physical CPU cores.  If all logical CPUs are tossed into the
same bucket (e.g. two hyperthreaded cores are reported as 4 siblings) then
there's not enough information for the scheduler to load-balance properly.  I'm
investigating now to see if we process the enumeration correctly.
Comment 20 Marty Wesley 2005-05-26 02:37:48 EDT
PM ACK for U6
Comment 26 Ernie Petrides 2005-07-20 03:50:16 EDT
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-33.EL).
Comment 31 Red Hat Bugzilla 2005-09-28 10:46:02 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Comment 34 Larry Troan 2007-01-05 10:07:57 EST
Comment I provided to a Red Hat Partner for one of its customers:

I should clarify Red Hat's and Intel's position on this matter. Yes, my
comment #14 in the referenced bugzilla states what you suggest but Intel
provided a clarification in comment #15. Therefore, the statement from
Red Hat should read...

 "For RHEL4U1/RHEL3U5, Red Hat suggests HT be turned off in the BIOS
  for Intel dual core processors. The CPUs will then appear as two
  (SMP) processors w/o HT. The concern is that the scheduler in those
  updates is unaware of the true machine structure and it MAY schedule
  things poorly depending on timing and the workload profile. Per
  Intel, the performance is non-deterministic. See Bug 147823 comment
  #15 for additional information from Intel.

  Intel provided a patch for RHEL4U2/RHEL3U6 that has better
  awareness of the true machine structure. Note that the RHEL4U2
  patch also takes full advantage of the enhanced RHEL4U1 scheduler
  changes but these scheduler changes were not back-ported to RHEL3U6
  due to the differences between the 2.4 and 2.6 kernels."

Note You need to log in before you can comment on or make changes to this bug.