Johnny Hughes mailing-lists@hughesjr.com wrote:
Just for the record, here are the default values for the kernel variable "CONFIG_NR_CPUS=" for the following arches: x86_64=1 x86_64.smp=8 i686=1 i686.smp=32 ppc=4 ppc64=64 s390=32 s390x=64 ia64=64 These values are the default values for RH ...
Because Red Hat has the hardware support.
You don't find >2 or >4 CPU i686 processors in the wild that don't have some sort of additional code required for the hardware. Red Hat has gotten that for the few Xeon and Itanium architectures. In reality, most of those are _proprietary_ implementations -- and _differ_ between vendors. GTL+ is very, very simplistic.
Opteron is clearly more of a "tier-2" solution right now (which has more to do with the AMD v. Intel lawsuit than anything), hence why you don't have a large volume of >4 CPU Opterons yet, and the code to support them. Consumers are trying to get HP to change -- e.g., Opterons comprised of 30% of there server sales at one point. Backorders are in the weeks, but not because of AMD stock. ;->
So there's been little reason for Red Hat to support more than 4xS940 in a system.
the only one I see as a major problem actually is x86_64
...
I would think that 8 might be too small with the dual core machines out there. I would think 4 dual core machines would show up as 8 CPUS ... anything more would probably not be recognized correctly.
Who says that any arbitrary 32-way Xeon platform will be recognized correctly with RHELv3/4? There are many cases only 2 processors will be recognized _despite_ the kernel setting.
Why? Again, beyond 2 or 4-way Xeon/Itanium, you're talking _proprietary_ implementations. They have extra bridging IC and APIC register support needed to support such. These are not "stock 1/2-way bridge/APIC compatible."
Currently we are not changing these values in either the main or centosplus kernels, but we might set all the smp supported config files to 64 in the centosplus kernel for future versions.
Again, it might not matter if the code to support the system interconnects are not standard. Granted, HyperTransport is quite commodity, and they are using a straight HyperTransport line from an Opteron 8xx CPU between boards. But there are serious hardware support questions that need to be addressed.
E.g., you can't just let the HyperTransport broadcasts ripple through a half-dozen HyperTransport links. That means the hardware has to add additional facilities for inter-board communication, meaning the OS has to know how to deal with them.
And it sounds like those haven't made it into the RHELv4 kernel yet.