Subject: Re: Multiprocessor with NetBSD ?
To: None <email@example.com>
From: Erik E. Fair <firstname.lastname@example.org>
Date: 06/03/2001 20:23:18
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
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
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...