Red Hat Bugzilla – Bug 147823
FEAT: RHEL3 U6: Enable dual-core processors from Intel
Last modified: 2013-08-05 21:12:51 EDT
Escalated to Bugzilla from IssueTracker
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.
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.
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
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.
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.
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.
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.
PM ACK for U6
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).
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 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."