Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!dg!rec
From: rec@dg.dg.com (Robert Cousins)
Newsgroups: comp.arch
Subject: Re: One aspect of bandwidth (backplane bus)
Message-ID: <131@dg.dg.com>
Date: 18 Apr 89 12:59:34 GMT
References: <407@bnr-fos.UUCP> <17500@obiwan.mips.COM> <17527@winchester.mips.COM> <17298@cup.portal.com> <7794@phoenix.Princeton.EDU>
Reply-To: rec@dg.UUCP (Robert Cousins)
Distribution: na
Organization: Data General, Westboro, MA.
Lines: 29

In article <7794@phoenix.Princeton.EDU> mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) writes:
>
>Excuse me, I'm a complete novice in this area, but is it necessary that
>_all_ the memory of each processor be shared, and thus be on a very
>fast and expensive bus?  
>
>Matt Kennel
>   mbkennel@phoenix.princeton.edu

Actually, this makes sense for the general case.  A large portion of the
average unix systems' RAM contains read-only data structures and code
which will be constant from boot to shutdown.  This can be replicated
throughout the system.  Approximately 40% of all CPU time on a Unix
machine (varies with load and OS release) is spent in the kernel.  THerefore,
if each CPU has a private copy of the kernel text, the code fetches from
this 40% of the time can stay away from the shared memory system.  In
effect, this reduces the system memory bandwidth by some large amount,
which will depend upon the cache and CPU configuration.  

However, there are noticeable applications where this fails.  These 
include kernels which are paged, swapped or otherwise change with time.
In this case, the management of replicated memories becomes somewhat
hardware and/or software intensive.  Interestingly enough, even this
disadvantage is not too much for some machines to still get a win out 
of it.

Robert Cousins

Speaking for myself alone.