Article View: comp.arch
Article #3007Re: RISC multiprocessors
From: Jim Barton
Date: Wed, 15 Nov 1989 18:43
Date: Wed, 15 Nov 1989 18:43
46 lines
3032 bytes
3032 bytes
In article <1989Nov15.040039.28570@Solbourne.COM>, stevec@momma.Solbourne.COM (Steve Cox) writes:
> In article <23963@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes:
> >Snooping directly on the primary R3000 cache is indeed possible, but as I
> >understand it, the degradation on CPU performance due to contention for the
> >cache is signficant. Plus, the R3000 cache is write-through, and a reasonable
> >multiprocessor system needs write-back caches. All multiprocessor R3000 system
> >I'm aware of use second-level write-back caches.
>
> second-level write-back caches? so (correct me if i am wrong), there
> is a first level cache that is not connected to the shared memory bus.
> how do these systems support cache coherency for data that is
> cached in the first level cache? sounds pretty hairy to me.
> or am i missing something?
>
>
> --
> steve cox stevec@solbourne.com
> solbourne computer, inc.
> 1900 pike, longmont, co GO BUFFS !!! ...
> (303)772-3400
The Stardent Titan machines snoop directly on the first level cache. The
R3000 has explicit lines (if you give up 128K caches and stick to 64K) to
stall and to allow you to invalidate the caches. These machines also
suffer a significant penalty for invalidate traffic, causing less than
stellar (pun intended) performance. The effect is mitigated by the
dual-bus scheme of the Titan. Instructions and read-only data pass
on a separate bus which is not snooped, and read/write data passes on a bus
which is. For instance, the vector units pick up their operands from
the read-only bus and write them to the read/write bus. Obviously, this
scheme doesn't work too well.
We may note also that there is only one R3000 based multiprocessor
announced and shipping. The Titan III has been announced in Japan,
but not here. The current Titan products are R2000 based.
The SGI POWERSeries has a second level cache which performs all the
snooping operations and does the writeback. In effect, it acts as a
"filter" which operates asynchronously to the processor. When a hit
occurs on an invalidate, and since the first level cache is (necessarily)
a subset of the second level cache, the second level cache turns around
and invalidates the first level cache. So, stevec missed something too.
-- Jim Barton
Silicon Graphics Computer Systems "UNIX: Live Free Or Die!"
jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb
Technical Details
Message-ID:
<44720@sgi.sgi.com>Path:
arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!decwrl!sgi!jmb@patton.sgi.comReferences:
<13319@pur-ee.UUCP> <280004@hpdml93.HP.COM> <23963@cup.portal.com> <1989Nov15.040039.28570@Solbourne.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!decwrl!sgi!jmb@patton.sgi.com From: jmb@patton.sgi.com (Jim Barton) Newsgroups: comp.arch Subject: Re: RISC multiprocessors Summary: Some Confusion Message-ID: <44720@sgi.sgi.com> Date: 15 Nov 89 18:43:44 GMT References: <13319@pur-ee.UUCP> <280004@hpdml93.HP.COM> <23963@cup.portal.com> <1989Nov15.040039.28570@Solbourne.COM> Sender: jmb@patton.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 46