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. Thanks, rohit
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. http://rhn.redhat.com/errata/RHSA-2005-663.html
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."