Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!Glacier!mips!mash
From: mash@mips.UUCP (John Mashey)
Newsgroups: net.arch
Subject: Re: Re: I don't believe your statements about multiprocessors
Message-ID: <134@mips.UUCP>
Date: Fri, 17-May-85 14:42:03 EDT
Article-I.D.: mips.134
Posted: Fri May 17 14:42:03 1985
Date-Received: Sun, 19-May-85 08:06:33 EDT
References: <7202@Glacier.UUCP> <36900002@ima.UUCP> <579@lll-crg.ARPA> <1775@cornell.UUCP>
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 30

J. Q. Johnson (..!cornell!jqj) writes:
> I guess I believe that, at least in principal, a multiprocessor could
> be preferable to an equivalent uniprocessor (= same aggregate througput,
> same total cache, etc.).  The argument is that both multiprocessor and
> uniprocessor suffer scheduler overhead, but that in some cases the
> overhead on a multiprocessor will be less.  A trivial example is a
> that scheduler only gets invoked when someone isn't currently running
> but wants to be)....... 

One can certainly find examples of this; in particular it is true if one
has n independent tasks that 1) are very compute bound 2) are small enough
that paging traffic is minimal.  Otherwise, what you find is that the OS
has to pay the price not in scheduling overhead, but in other coordination
overhead.  For example, either you use snoopy caches [and chew up bandwidth
and basic cycle time] or handle cache consistency by various software
mechanisms.  Next, you have to handle TLB consistency, and then you must
interlock terminal I/O, disk cache I/O, etc.  In every MP implementation I've
seen, you always had to add code to interlock against rare events.
Hence, as long as you stay in user programs, you can be OK, but as soon as
you spend significant time in the kernel, you pay some coordination price.
[Note: the above applies to general-use, not special-case systems.]

Complexity is like garbage.  Hard work can keep the amount down, but
won't make it go away.  If you sweep it under the rug you'll be sorry.
At best, you can at least choose a good location for the garbage dump.
-- 
-john mashey
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD:  	415-960-1200
USPS: 	MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043