Detecting SMP

Detecting SMP

[Burton Windle]

Hello. Is there a way, when running a non-SMP kernel, to detect or
otherwise tell (software only; the machine is 2400 miles away) if the
system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
kernel is non-SMP?  Thanks!

(btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I 
know I should update it anyways and that a SMP kernel will run on a UP
system)

-- 
Burton Windle				burton@fint.org
Linux: the "grim reaper of innocent orphaned children."
          from /usr/src/linux-2.4.0/init/main.c:655

Re: Detecting SMP

[Tigran Aivazian]

yes, just run the famous mptable program. If the machine is SMP then it
will have a valid Intel MP 1.4 configuration tables so the program will
show meaningful output.

Regards,
Tigran

On Tue, 20 Feb 2001, Burton Windle wrote:

> Hello. Is there a way, when running a non-SMP kernel, to detect or
> otherwise tell (software only; the machine is 2400 miles away) if the
> system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
> kernel is non-SMP?  Thanks!
> 
> (btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I 
> know I should update it anyways and that a SMP kernel will run on a UP
> system)
> 
> 

Re: Detecting SMP

[Jeff Garzik]

On Wed, 21 Feb 2001, Tigran Aivazian wrote:
> yes, just run the famous mptable program. If the machine is SMP then it
> will have a valid Intel MP 1.4 configuration tables so the program will
> show meaningful output.

Does that allow you to detect multiple processors... or just an SMP board?

	Jeff

Re: Detecting SMP

[Tigran Aivazian]

On Wed, 21 Feb 2001, Jeff Garzik wrote:

> On Wed, 21 Feb 2001, Tigran Aivazian wrote:
> > yes, just run the famous mptable program. If the machine is SMP then it
> > will have a valid Intel MP 1.4 configuration tables so the program will
> > show meaningful output.
> 
> Does that allow you to detect multiple processors... or just an SMP board?
> 

the answer is in section 4.1 of the Intel MP 1.4 spec:

   "An MP-compliant system must implement the MP floating pointer
    structure, ..."

So, one would normally expect this to mean an SMP board rather than
multiple processors, _HOWEVER_, I can imagine a very clever MP-aware BIOS
implementation which detects that there are many processors and prepares
MP floating config table and does _not_ prepare it otherwise. So, it all
depends on the BIOS implementation.

Actually, I never tried unplugging all-1 processors from my SMP machines
and seeing what sort of MP table is left...

Regards,
Tigran

Re: Detecting SMP

[Tigran Aivazian]

On Wed, 21 Feb 2001, Tigran Aivazian wrote:

> yes, just run the famous mptable program.

before I am snowed under with questions about where to get this program,
here is the src and binaries that I use -- it is quite possible that there
is a newer version (I suspect Ingo Molnar might know better :)

http://www.moses.uklinux.net/mptable

Regards,
Tigran

Re: Detecting SMP

[Maciej W. Rozycki]

On Wed, 21 Feb 2001, Tigran Aivazian wrote:

> So, one would normally expect this to mean an SMP board rather than
> multiple processors, _HOWEVER_, I can imagine a very clever MP-aware BIOS
> implementation which detects that there are many processors and prepares
> MP floating config table and does _not_ prepare it otherwise. So, it all
> depends on the BIOS implementation.

 I've seen systems that do so and while it's not forbidden I consider it a
bad thing.  It prevents us from being able to use I/O APICs.

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

Re: Detecting SMP

[Mike A. Harris]

On Tue, 20 Feb 2001, Burton Windle wrote:

>Hello. Is there a way, when running a non-SMP kernel, to detect or
>otherwise tell (software only; the machine is 2400 miles away) if the
>system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
>kernel is non-SMP?  Thanks!
>
>(btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I
>know I should update it anyways and that a SMP kernel will run on a UP
>system)

Yes, there are several ways.  How do you want to know how to do
it, in C, or a bash script?  sysconf is one way, parsing
/proc/cpuinfo and /proc/stat is another.  Beware though, if you
parse /proc/cpuinfo or stat, it is very different on different
architectures, particularly sparc.

Here is some code which should do it more or less correctly on
any arch:

ncpus=$(egrep -c ^cpu[0-9]+ /proc/stat || :)
[ "$ncpus" = "0" ] && ncpus=1


----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Free Software advocate
          This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
    printf("Don't Panic!\n");
    exit(42);
}

apic patches (with MIS counter)

[Roeland Th. Jansen]

Maciej,

with the patch you sent (with MIS counter code) :

           CPU0       CPU1
  0:   50644222   50826974    IO-APIC-edge  timer
  1:     239631     233690    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
  3:     344151     345715    IO-APIC-edge  serial
  4:          4          4    IO-APIC-edge  serial
  5:     331569     327717    IO-APIC-edge  soundblaster
  8:     268433     271449    IO-APIC-edge  rtc
 14:     919801     913328    IO-APIC-edge  ide0
 15:      22625      21407    IO-APIC-edge  ide1
 18:     149973     150537   IO-APIC-level  BusLogic BT-930
 19:    5557525    5554806   IO-APIC-level  eth0
NMI:  101420638  101425054
LOC:  101475956  101475952
ERR:         90
MIS:      34865

and  11:09am  up 11 days, 17:52,  8 users,  load average: 1.44, 1.15,
     0.77 uptime.

it seems like it is time to get at least the suggestions so far in the
mainstream kernel or at least in Alan's tree. (it's not clear if it has
been already included)

There are a few things that might be related though -- some slow network
performance but I am not sure if that is caused by the patch. I don't
think so but..; I also didn't hammer the whole day on sound to crash it.
typically, a flood ping, sound & backup --> crash within minutes and I
wanted to see how it performs (e.g. no crash) under normal loads. that
part succeeded.

if you like, I can start banging the machine on it's head now.


-- 
Grobbebol's Home                   |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel       | Use your real e-mail address   /\
Linux 2.2.16 SMP 2x466MHz / 256 MB |        on Usenet.             _\_v  

Re: apic patches (with MIS counter)

[Maciej W. Rozycki]

On Mon, 26 Feb 2001, Roeland Th. Jansen wrote:

>            CPU0       CPU1
>   0:   50644222   50826974    IO-APIC-edge  timer
>   1:     239631     233690    IO-APIC-edge  keyboard
>   2:          0          0          XT-PIC  cascade
>   3:     344151     345715    IO-APIC-edge  serial
>   4:          4          4    IO-APIC-edge  serial
>   5:     331569     327717    IO-APIC-edge  soundblaster
>   8:     268433     271449    IO-APIC-edge  rtc
>  14:     919801     913328    IO-APIC-edge  ide0
>  15:      22625      21407    IO-APIC-edge  ide1
>  18:     149973     150537   IO-APIC-level  BusLogic BT-930
>  19:    5557525    5554806   IO-APIC-level  eth0
> NMI:  101420638  101425054
> LOC:  101475956  101475952
> ERR:         90
> MIS:      34865

 The mismatch to IRQ count ratio looks sane. 

> it seems like it is time to get at least the suggestions so far in the
> mainstream kernel or at least in Alan's tree. (it's not clear if it has
> been already included)

 It is already present in 2.4.2-ac3.

> There are a few things that might be related though -- some slow network
> performance but I am not sure if that is caused by the patch. I don't
> think so but..; I also didn't hammer the whole day on sound to crash it.

 There is a small performance impact at every interrupt -- the code that
checks for mismatches incurs it.  It's just a few CPU instructions, thus
it should not be noticeable.

> if you like, I can start banging the machine on it's head now.

 Please do.  I believe the code is safe to be included in 2.4.3, but if
any problem is going to pop up, it'd better do it before than after
applying to the mainstream. 

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

Re: apic patches (with MIS counter)

[Roeland Th. Jansen]

On Mon, Feb 26, 2001 at 01:14:11PM +0100, Maciej W. Rozycki wrote:
>  It is already present in 2.4.2-ac3.


Yep, I just noticed it. there was a backlog from here to tokyo.

>  There is a small performance impact at every interrupt -- the code that
> checks for mismatches incurs it.  It's just a few CPU instructions, thus
> it should not be noticeable.


well I saw a lot of collisions on the hub and a slow speed (approx
150kbytes sec) but I don't think collisions & patch is the cause
:-)

> > if you like, I can start banging the machine on it's head now.
> 
>  Please do.  I believe the code is safe to be included in 2.4.3, but if
> any problem is going to pop up, it'd better do it before than after
> applying to the mainstream. 

ok, it's box killing time. I just installed a new kernel with the ptches
and some additions and will reboot after I tried to kill the system.
will report here.

-- 
Grobbebol's Home                   |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel       | Use your real e-mail address   /\
Linux 2.2.16 SMP 2x466MHz / 256 MB |        on Usenet.             _\_v  

Re: apic patches (with MIS counter)

[Roeland Th. Jansen]

On Mon, Feb 26, 2001 at 01:14:11PM +0100, Maciej W. Rozycki wrote:
> On Mon, 26 Feb 2001, Roeland Th. Jansen wrote:
> > if you like, I can start banging the machine on it's head now.
> 
>  Please do.  I believe the code is safe to be included in 2.4.3, but if
> any problem is going to pop up, it'd better do it before than after
> applying to the mainstream. 


banged the box quite a bit. so far no weird things like lockups. 
still 2.4.1. with the MIS counter (etc) patch.

-- 
Grobbebol's Home                   |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel       | Use your real e-mail address   /\
Linux 2.2.16 SMP 2x466MHz / 256 MB |        on Usenet.             _\_v  

Re: Detecting SMP

[Jay D Allen]

What is the platform ( x86, Sparc, alpha or ?)?  On sparc look in the
bootprom (ls /proc/openprom) that works regardless of kernel SMP status.
On Intel I think your out of luck, at least with the commonly available
hardware/software.  In theory there could be a bios-peeking structure in
/proc much like openprom that could give you hints...



Sent by:  linux-kernel-owner@vger.kernel.org

To:   linux-kernel@vger.kernel.org
cc:
Subject:  Detecting SMP



Hello. Is there a way, when running a non-SMP kernel, to detect or
otherwise tell (software only; the machine is 2400 miles away) if the
system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
kernel is non-SMP?  Thanks!

(btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I
know I should update it anyways and that a SMP kernel will run on a UP
system)

--
Burton Windle                 burton@fint.org
Linux: the "grim reaper of innocent orphaned children."
          from /usr/src/linux-2.4.0/init/main.c:655

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/