Johnny Hughes <mailing-lists@xxxxxxxxxxxx> 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.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
