SMP Upgrade

Purpose of This Document

An uncommon area of computing involves machines with multiple processors. These days they are almost exclusively symmetrical multi-Processor (SMP) systems. This short document gives an overview of a recent upgrade of my workstation from a single processor to a dual processor SMP system.

Scope of This Document

This is not intended to be advice, just a brief informational document.

The Old Machine

My workstation was an older single-processor 850 MHz Athlon. This was purchased before the days the "1GHz barrier" was broken and 850MHz was state of the art. The general specifications are thus:

Category Item
CPU 850 MHz Athon
RAM 1GB PC-100
Hard Drive 3ware Escalade 6200 RAID Controller with two 40GB hard drives configured as a single 40GB RAID-1 device.
Video Matrox Millennium G400
Monitor ViewSonic G90f

Category	Item
CPU	850 MHz Athon
RAM	1GB PC-100
Hard Drive	3ware Escalade 6200 RAID Controller with two 40GB hard drives configured as a single 40GB RAID-1 device.
Video	Matrox Millennium G400
Monitor	ViewSonic G90f

As you can see, some parts have been updated over the years. For example, the monitor was a Princeton EO-90 before it died a sad death.

The Upgrade

Rationale

In the course of a project that I'm working, we need to validate an XML respository server that I wrote to ensure it functions properly on both single- and multi-processor machines. Debugging and validating multi-threading software on multiple CPUs is a very different animal than a single CPU.

With a single CPU, nothing happens simultaneously. Multiple threads do not run at the same time, but are run for a short time before being paused to allow the next thread to run. Because there is only one processor, which can only do one thing at a time, this behaviour is very convenient for software development because it is predictible.

Adding processors allow operations to be run simultaneously. At this point, the world of software debugging becomes surreal. One can no longer set breakpoints and emit debugging information without affecting program behaviour. It is somewhat reminiscient of the quantum world in that observing a running system alters timings, which can radically alter its behaviour.

Because wierd things happen with multiple CPUs, the required software validation must take place on an SMP machine.

I've traditionally waited to upgrade my workstation until the clock speed of the CPU doubled. Seeing how I have to validate the software on a mutliple CPU system, combined with the fact that 850 MHz is very much passé, time was ripe to make the leap back into the SMP world. (Back? Yes, I've long had my fingers in parallel processing, starting with transputers in the late 1980's.)

The Hardware

Wanting to minimize costs without shooting ourselves in the foot by hampering performance, we finally decided to upgrade the following parts. For people familiar with SMP machines, this is the minimal amount needed.

Category Item
Motherboard ASUS A7M266-D, revision 1.04 Note that motherboard revisions before 1.04 cannot handle CPUs faster than the Athlon 1900+.
CPU Two Athlon 2400+ MP processors
RAM 1GB PC-2100 in two 512MB sticks.
Power Antec TruePower 480W ATX12V Note that this motherboard requires the more powerful power supply with the extra connectors. 480W is more than needed, but the vendor that I bought everything from didn't have a 430W power supply in stock.
HD same We found no need to update either the RAID controller or video card. Keeping them is not going to fundamentally slow the system down.
Video same
Monitor same

Category	Item
Motherboard	ASUS A7M266-D, revision 1.04	Note that motherboard revisions before 1.04 cannot handle CPUs faster than the Athlon 1900+.
CPU	Two Athlon 2400+ MP processors
RAM	1GB PC-2100 in two 512MB sticks.
Power	Antec TruePower 480W ATX12V	Note that this motherboard requires the more powerful power supply with the extra connectors. 480W is more than needed, but the vendor that I bought everything from didn't have a 430W power supply in stock.
HD	same	We found no need to update either the RAID controller or video card. Keeping them is not going to fundamentally slow the system down.
Video	same
Monitor	same

Operating System

First Check

My workstation was running a stock RedHat 7.3 because I extensively use VMWare on the workstation. VMWare is not certified for RedHat 8.0. While I finally got VMWare to run on RedHat 8.0, I wasn't comfortible with the stability of the system, so I left my workstation at version 7.3.

After installing the hardware, I booted the machine. The BIOS warned "CPU1 is not MP capable." This had me worried that I damaged the CPU. (I later determined by Googling that upgrading the BIOS should fix this. I've downloaded the new BIOS but haven't installed it yet.)

The machine otherwise booted with various hardware drivers failing. This was not too surprising, as the motherboard has more recent USB hardware, and has on-board audio. Kudzu reconfigured the hardware flawlessly.

Examining the system, it appeared to be a flawless single-processor upgrade. Things were, of course, very fast compared to the old hardware. The reason Linux was running on a single processor is that in order to use multiple CPUs, one must use a kernel that has been created specifically for multiple CPUs.

Installing the SMP Kernel

After ensuring that I had a valid boot floppy, in case of disaster, I used RPM to install the SMP kernel on the RedHat CDs.

rpm -Uhv kernel-smp-2.4.18-3

This worked flawlessly. Hmmmm... too good to be true?

Verifying the SMP Kernel

Rebooting brought up GRUB with two kernel options, the SMP kernel, and the original kernel. It defaulted to the original kernel, so I selected the SMP kernel, and let it boot. This, too, worked flawlessly. Now for the moment of truth.

XOSview

Logging in, the first thing I noticed was xosview. This is an old X-windows application that I personally have been quite fond of for years. I always have it running in the upper-right corner of my desktop. I noticed that it was showing two CPUs.

XOSview displays quite a bit of information about the system graphically. The displays can be configured to show current values, historic graphs, etc. Though an incomplete list, xosview can be configured to display information such as

system load,
CPU utilization,
memory and swap use,
number of pages per second,
number of bytes per second in and out of the network card
number of bytes read and written to the disk subsystem,
interrupt activity.

Here is an example of what it looks like.

I have the interrupt activity display turned off, as I generally find it not very useful. If you like blinking lights, though, the interrupt activity display is very soothing.

/proc

The next thing that I checked was the /proc pseudo-filesystem, which exposes some of the internals of the running kernel.

jamesk@sherizod:~ :-) cat /proc/cpuinfo 
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model       : 8
model name  : AMD Duron(TM) MP Processor
stepping    : 1
cpu MHz     : 2000.085
cache size  : 256 KB
fdiv_bug    : no
hlt_bug     : no
f00f_bug    : no
coma_bug    : no
fpu     : yes
fpu_exception   : yes
cpuid level : 1
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
                    cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips    : 3984.58

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 6
model       : 8
model name  : AMD Duron(TM) MP Processor
stepping    : 1
cpu MHz     : 2000.085
cache size  : 256 KB
fdiv_bug    : no
hlt_bug     : no
f00f_bug    : no
coma_bug    : no
fpu     : yes
fpu_exception   : yes
cpuid level : 1
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
                    cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips    : 3997.69

Woo hoo! The kernel is running on two CPUs. I have no idea why it shows the CPUs as Duron MPs, which don't exist. I assume that this is becuase the kernel isn't the "lastest and greatest."

Top

Here's top, showing the two CPUs:


 6:15pm  up  8:34,  2 users,  load average: 0.24, 0.35, 0.43
119 processes: 118 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:  0.0% user,  0.2% system,  0.0% nice, 99.3% idle
CPU1 states:  5.4% user, 16.0% system,  0.0% nice, 77.4% idle
Mem:  1030972K av, 1009348K used,   21624K free,       0K shrd,   19744K buff
Swap:  522104K av,   36512K used,  485592K free                  896800K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1819 jamesk    15   0  1160 1064   960 S     5.9  0.1   0:38 xosview
 1657 root      15   0 72892 9556  3488 S     3.7  0.9  58:19 X
 1083 tomcat4   15   0 17372 7532  3620 S     2.9  0.7   0:15 java
 1812 jamesk    15   0  3108 2692  2580 S     2.1  0.2   1:21 magicdev
 1800 jamesk    15   0  1692 1524  1336 S     1.1  0.1   0:01 xscreensaver
 1080 tomcat4   15   0 17372 7532  3620 S     0.9  0.7   0:01 java
 1087 root      15   0  4140 1632  1584 S     0.9  0.1   0:01 httpd
  825 root      15   0   216  172   116 S     0.5  0.0   0:30 3dmd
11106 jamesk    15   0 12412  11M  8716 S     0.3  1.1   0:05 nautilus
11943 jamesk    16   0  1104 1104   848 R     0.3  0.1   0:00 top
    1 root      15   0   472  432   416 S     0.1  0.0   0:04 init
11821 jamesk    15   0  4444 4444  3540 S     0.1  0.4   0:00 gnome-terminal
    2 root      15   0     0    0     0 SW    0.0  0.0   0:00 keventd
    3 root      34  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd_CPU0
    4 root      34  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd_CPU1
    5 root      15   0     0    0     0 SW    0.0  0.0   0:04 kswapd

Stability

After fiddling with things a bit, including running VMWare, the machine appears to be rock solid.

Altering GRUB

Forcing GRUB to default to the SMP kernel was the last thing to do. This was a simple edit to /boot/grub/grub.conf. I changed the line

default=1

default=0

Closing Remarks

A very handy feature of having the two Linux kernels installed is the fact that I can boot to either one or two processors. I was expecting to have to use another machine to validate software on a single CPU, but the test suite simply needs to be run on the single-processor kernel.

I'm elated about how smooth the hardware and operating system upgrade went. I've done this before with the "other" OS, which I'll consider an unfortunate part of my life.