how many cpus can linux support for SMP?

how many cpus can linux support for SMP?

[Barry Wu]

Hi, all,

I am new to this mail list. I do not know how many CPUs linux can
support well using SMP. If some one knows, please give me
a reply. Thanks.

Barry


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: how many cpus can linux support for SMP?

[Thomas Duffy]

On Wed, 2002-01-16 at 22:59, Barry Wu wrote:
> Hi, all,
> 
> I am new to this mail list. I do not know how many CPUs linux can
> support well using SMP. If some one knows, please give me
> a reply. Thanks.

there is a 32bit cpu mask, meaning 32 is the absolute max, although Ralf
Baechle has extended it to 64 in order to support SGI origin 2000's, but
realistically, linux can only do about 8 before falling on the ground...

depends on your workload really...you should be ok with 4 cpus.

-tduffy

Re: how many cpus can linux support for SMP?

[Anton Blanchard]

 
> there is a 32bit cpu mask, meaning 32 is the absolute max, although Ralf
> Baechle has extended it to 64 in order to support SGI origin 2000's, but
> realistically, linux can only do about 8 before falling on the ground...

Its actually the number of bits in a long so 64 bit archs can boot 64
cpus. I think Kanoj had a hack to do a 128 cpu boot on SGI hardware.

Anton

Re: how many cpus can linux support for SMP?

[Robert Love]

On Thu, 2002-01-17 at 01:59, Barry Wu wrote:

> I am new to this mail list. I do not know how many CPUs linux can
> support well using SMP. If some one knows, please give me
> a reply. Thanks.

32.

"well" though may mean many things and the answer depends on your
workload.

	Robert Love

Re: how many cpus can linux support for SMP?

[Ralf Baechle]

On Wed, Jan 16, 2002 at 11:36:19PM -0800, Thomas Duffy wrote:

> > I am new to this mail list. I do not know how many CPUs linux can
> > support well using SMP. If some one knows, please give me
> > a reply. Thanks.
> 
> there is a 32bit cpu mask, meaning 32 is the absolute max, although Ralf
> Baechle has extended it to 64 in order to support SGI origin 2000's, but
> realistically, linux can only do about 8 before falling on the ground...

Actually Kanoj and me hacked it to work with 128.  The scalability was
already frightening with 32 and even more so with 128 ...

> depends on your workload really...you should be ok with 4 cpus.

Around 4 procs is certainly the sweet spot currently.

  Ralf

--
"Embrace, Enhance, Eliminate" - it worked for the pope, it'll work for Bill.

Re: how many cpus can linux support for SMP?

[Randy.Dunlap]

On 17 Jan 2002, Robert Love wrote:

| On Thu, 2002-01-17 at 01:59, Barry Wu wrote:
|
| > I am new to this mail list. I do not know how many CPUs linux can
| > support well using SMP. If some one knows, please give me
| > a reply. Thanks.
|
| 32.
|
| "well" though may mean many things and the answer depends on your
| workload.

On x86, using APICs, Pentium III maximum is 15 due to APIC addressing.
The IBM multiquad patch uses different APIC addressing (physical vs.
logical), so it goes beyond 15.
Pentium 4 APICs have addressing up to 255 IIRC, so they can do more
than P-III's 15.

-- 
~Randy

Re: how many cpus can linux support for SMP?

[James Cleverdon]

On Thursday 17 January 2002 11:43 am, Randy.Dunlap wrote:
> On 17 Jan 2002, Robert Love wrote:
> | On Thu, 2002-01-17 at 01:59, Barry Wu wrote:
> | > I am new to this mail list. I do not know how many CPUs linux can
> | > support well using SMP. If some one knows, please give me
> | > a reply. Thanks.
> |
> | 32.
> |
> | "well" though may mean many things and the answer depends on your
> | workload.
>
> On x86, using APICs, Pentium III maximum is 15 due to APIC addressing.
> The IBM multiquad patch uses different APIC addressing (physical vs.
> logical), so it goes beyond 15.

Minor nitpick:  multiquad uses clustered logical (aka hierarchal) mode.

> Pentium 4 APICs have addressing up to 255 IIRC, so they can do more
> than P-III's 15.

Yup.  xAPICs (and SAPICs for IA64) are the only ones that can get beyond 14 
(0x0F is the broadcast ID) using physical addressing.  I'm kicking around 
some patches that use physical mode on a xAPIC NUMA box.

-- 
James Cleverdon, IBM xSeries Platform (NUMA), Beaverton
jamesclv@us.ibm.com   |   cleverdj@us.ibm.com

Re: how many cpus can linux support for SMP?

[Maciej W. Rozycki]

On Fri, 18 Jan 2002, James Cleverdon wrote:

> > Pentium 4 APICs have addressing up to 255 IIRC, so they can do more
> > than P-III's 15.
> 
> Yup.  xAPICs (and SAPICs for IA64) are the only ones that can get beyond 14 
> (0x0F is the broadcast ID) using physical addressing.  I'm kicking around 
> some patches that use physical mode on a xAPIC NUMA box.

 Note that the original i82489DX supported up to 255 APICs (0xff being the
broadcast ID), so that's really nothing new and xAPICs are not the only
ones.  Of course, i82489DX provides 32-bits for addressing in the logical
mode. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: how many cpus can linux support for SMP?

[James Cleverdon]

On Friday 18 January 2002 05:41 pm, Maciej W. Rozycki wrote:
> On Fri, 18 Jan 2002, James Cleverdon wrote:
> > > Pentium 4 APICs have addressing up to 255 IIRC, so they can do more
> > > than P-III's 15.
> >
> > Yup.  xAPICs (and SAPICs for IA64) are the only ones that can get beyond
> > 14 (0x0F is the broadcast ID) using physical addressing.  I'm kicking
> > around some patches that use physical mode on a xAPIC NUMA box.
>
>  Note that the original i82489DX supported up to 255 APICs (0xff being the
> broadcast ID), so that's really nothing new and xAPICs are not the only
> ones.  Of course, i82489DX provides 32-bits for addressing in the logical
> mode.

True.  I wish that the ID size was the only thing that regressed when local 
APICs moved onto the CPU chip with the P54C.  Intel removing the ability to 
accept all interrupts and introducing new, poorly tested error states to 
"deal" with this limitation has haunted my code ever since....

-- 
James Cleverdon, IBM xSeries Platform (NUMA), Beaverton
jamesclv@us.ibm.com   |   cleverdj@us.ibm.com