The whole point of having a multi-CPU hardware configuration is to 
get a factor of N speed up, for each Nth processor (e.g. a factor of 
two for two processors), in system throughput (N.B. I do not suggest 
that an SMP will speed up individual applications - that depends on 
whether they have been specially coded to take advantage of 
additional CPUs, when present).

Given this goal, the OS kernel must be fully symmetric and re-entrant 
on all processors with fine-grain locking. Otherwise, a system-call 
bound process on one processor (or lots of I/O interrupts) will cause 
the kernel to be the performance bottleneck if only one processor can 
field interrupts, or handle system calls. Even one processor, at a 
time. Unless the job mix is totally dominated by user CPU, you would 
end up with a queue of processes waiting for kernel time, and idled 
CPUs.

In order for a parallel system to provide maximum throughput, 
contention for common resources must be minimized, and that means the 
kernel has to be parallelized enough that N processes on N CPUs can 
make N different system calls, and no one waits for any other.

Now, I'm not saying that you won't have contention; if every process 
wants to read the same I/O device, someone has to wait. However, so 
long as the processes are asking for different resources at the same 
time, we should try to make it possible for each the processors to 
handle those requests in parallel, so everyone can be running 
flat-out.

Anything less is not SMP. It's MP. Whether this is a really big deal 
or not depends on your job mix, and/or your marketing message.

We're lucky in one sense: UNIX is process-happy - want to get 
something done? Start a new process! Given that, adding processors to 
a UNIX system generally does help things significantly (provided 
you've also got memory subsystem and bus bandwidth, etc).

	pick, pick, pick...

	Erik <fair@clock.org>