(Picking back..)

	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
	alone.

	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
> 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>
>