Subject: Re: Multiprocessor with NetBSD ?
To: Erik E. Fair <firstname.lastname@example.org>
From: David Brownlee <email@example.com>
Date: 06/04/2001 10:00:49
I'm not aware of any system that will give "a factor of N
speed up, for each Nth processor". I do not believe it
possible for inherent reasons of memory and i/o contention
So... if percentage speed up is not a valid metric for SMP,
how ahout "re-entrant on all processors with fine-grain
locking". How re-entrant and fine-grain do you need to be
to qualify. NetBSD is trivially re-entrant for one syscall
- getpid(), but should it be all syscalls? - all i/o?
locking on every structure access?
You could draw a line somewhere and say "these are the
characteristics that define SMP". Unless you draw it so
high that virtually no existing system can qualify, then
someone could come up with a system that just fails on one
criteria, but exceeds the others by such a degree that it
should be called SMP.
David/absolute -- www.netbsd.org: No hype required --
On Sun, 3 Jun 2001, Erik E. Fair wrote:
> 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...
> Erik <firstname.lastname@example.org>