RE: Dual CPU for Linux 7.2

There are three versions of the Linux OS usually available for installation
	1. The regular single cpu version.
	2. The Multiprocessor version - file name will have the text string  smp
for Symmetric Multiprocessor
		as part of the name
	3. The very large memory versions of recent vintage. They have bigmem as
part of the filename,
	may also have smp in the name as well.

	The "uname -a" command should show you which one is running. IE.
		prompt> uname -a <RETURNKEY>
			hostname etcetra....  2.4.2-2smp #1 SMP ... i686 unknown

Check to see what is installed under your /boot directory. You either did
not load this machine
with the SMP version to begin with, GRUB/LILO is pointed at the single cpu
version instead of the SMP
version, or there is not enough load for SMP to schedule both CPU's.

contrary to popular rumor, SMP systems do not wait for cpu # 0 to become
"taxed". The scheduler will
assign all runnable processes to any available processor at all times. IE.
It will load balance the
active programs across all available cpu's. So either you dont have suffice
load during your tests to
show more than one cpu in use, or you have the single cpu version of the
kernel loaded. Perhaps you
installed the workstation version of linux  which would default to the
single cpu model.

Check what is running. If it looks like you have SMP running, you can create
a load by firing up at least
N + 1 windows , where N  is the number of CPU's in your system - run top in
one window, compile and run some C code like the following and run it
separately in each of the other windows. It is an infinite loop compute
intensive program that the scheduler should keep assigned to the CPU until
the maximum time slice per process limit is reached.
Ie it will try to constantly occupy a CPU until you kill it manually. Run
one per CPU to keep all busy and TOP
and the standard daemons will preempt them as needed at the end of their
time slice allocation.

Not knowing if you are a C programmer
use a plain text editor like Vi, ED , emacs to create a plain ascii file
named say  "t.c"
containing the following.

main(int argc, char **argv, char **envp)
{
	int	i = 0;
	int	j = 0;
	double	f = 0.0;

	for(;;) {
		i++;
		j++;
		f += 1.25;
	}
}

save it to disk, type command "cc -O -o t t.c" to create the program "t"

open up your multiple console windows, and run a system monitor (SM) (see
comment below) in one, and  "t" in each of the others.
do NOT include the " marks in your typing. I would suggest linking or
copying "t" to the program
names t1, t2,m t3, t4, .... tN so that SM will show each separate T program
uniquely as it runs on each CPU

The SM should then show all CPU's running this "T" program constantly unless
other programs preempt it
if the SMP kernel is running. If not SMP, then only one "T" program will
show running at a time.

If you are not a SMP version of the OS and none is in /boot, then you will
need to extract it off the CDROM's
manually, and make sure GRUB/LILO show sit at boot and manually select it
during an initial test period.

If this is a new installation not in production use, I would just
reinstall/upgrade the system
specifying the multiprocesser kernel and server mode. Others familiar with
this process can help you further.

SM - system monitor - Neither TOP or GTOP are adequate for this task. Both
show CPU as the cumulative number across all CPU's. You cant therefore tell
if CPU0 is supporting 100%, 50% or 10% of the current
program load. If you have both of your cpu's running at 50% load, TOP will
show a 50% load.
You need a tool like HP's Glanceplus or a ported version of the Adrian
Cockcroft Group's system tool kit (RICHPse) under the Symbel language
available at the SUN website (www.sun.com, search on Cockcroft). Others may
be able to suggest tools already ported to linux that have the needed
capability. Both these tools,
which I have used on SUN systems, show CPU utilization on a per CPU basis.
You actually get a bar or line graph
that shows the utilization percent for each CPU as an independant unit. Each
CPU in the system is a separate
bar graph so that you can dynamically watch the load on all processors. The
detail screen shows what programs
are assigned to what CPU's. the "top's" dont apear to have this level of
detail configurable.

During a brief scan of my RH7.1 system here, I could not immediately locate
such a tool for linux
under the gnome desktops Systems, applications, utilities lists.



++> -----Original Message-----
++> From: [email protected]
++> [mailto:[email protected]]On Behalf Of Keith Mastin
++> Sent: Thursday, March 06, 2003 10:21 AM
++> To: [email protected]
++> Subject: Re: Dual CPU for Linux 7.2
++>
++>
++>
++> > Hello folks,
++> >
++> > I've just installed RH 7.2 on Intel workstation
++> > with two Xeon processors.
++> >
++> > I have no indication that RH utilizes both processors.
++> > It seems that only one runs.
++> > gmesg shows only cpu#0 initialization,
++> > gtop shows only one cpu.
++> >
++> > Maybe sombedy faced similar problem? How should i
++> > configure system to run on two cpus?
++> >
++> > Thanks for your contribution,
++> > Gary.
++>
++> You're assumming that both CPUs should be running all the
++> time. This is
++> not the case. The second CPU shouldn't kick in until the
++> first is taxed.
++> What you have to do is overload the first CPU while monitoring with
++> something like top.
++>
++> Open a few shells with database queries that run and then
++> some graphics
++> apps, something really CPU intensive. That may kick in the
++> second puter.
++> If not, and if you can sit at the console and kill the
++> machine, there is a
++> null command replicator string that you can run in a shell that will
++> respawn itself over and over. This used to work on older
++> machines, whether
++> it will work on newer systems with a ton of power is to be
++> seen. Maybe you
++> can tell us? :)
++>
++> Here's the string. *_Do _Not_* run this on a production
++> system. You've
++> been warned.
++>          :(){ :|:& };:
++>
++> What this lines tries to do is to keep on loading null
++> command, after null
++> command, and it also pipes them to each other. Notice the
++> '|', which does
++> the piping in between the null shells.
++>
++> This runs in the background, in order to slow down the
++> system even more.
++> Basically, this program just tries to load empty shell,
++> after another one,
++> until your operating system realizes that you have too many
++> of them open,
++> and it tries to close them.
++>
++> Let us know what the results are. I'm curious.
++>
++> Cheers!
++>
++> --
++> Keith Mastin
++> BeechTree Information Technology Services Inc.
++> Toronto, Canada
++> (416)696-6070
++>
++>
++>
++>
++> _______________________________________________
++> enigma-list mailing list
++> [email protected]
++> https://listman.redhat.com/mailman/listinfo/enigma-list
++>