Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!sun!gnu
From: gnu@sun.uucp (John Gilmore)
Newsgroups: net.arch
Subject: Re: Cache revisited
Message-ID: <2583@sun.uucp>
Date: Thu, 8-Aug-85 20:51:58 EDT
Article-I.D.: sun.2583
Posted: Thu Aug  8 20:51:58 1985
Date-Received: Mon, 12-Aug-85 02:34:52 EDT
References: <5374@fortune.UUCP> <901@loral.UUCP>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 41

John Van Zandt of Loral Instrumentation (ucbvax!sdcsvax!jvz) said:
> Cache's are strange creatures, exactly how they are designed can impact
> performance significantly.  Your idea of separate cache's for supervisor
> and user is a good one.
I believe (uninformed opinion) that this makes it perform worse, all
other things equal.  It means that at any given time, half the cache
is unusable, thus if you spend 90% of your time in user state you
only have a halfsize cache.  (Ditto if you are doing system state stuff.)

>                                                  I haven't checked the
> M68000 lately, but if lines coming from the chip can signal whether
> an instruction or data fetch is occuring, then another speedup would be
> to have separate instruction and data cache's.
The 68000 signals supervisor/user as well as instruction/data.

Again, this creates an artificial split.  If indeed the CPU is spending
50% of its time on instruction fetches and 50% on data cycles, this
could be OK, but it won't adapt dynamically as the instruction/data
mix changes.

> >                                              If the CPU were a 
> >68020 with the internal 256 byte direct mapped instruction cache, is 
> >there a need for the external cache?
> Again, depends on the hits for the internal cache; but my guess is that the
> internal cache does not take into account the different spaces (supervisor
> and user), therefore the external cache would give better performance on
> context switches.
The internal instruction cache on the 68020 definitely takes supervisor/user
mode into account.  It does NOT take context switches into account, thus it
must be flushed on context switch.  I believe the hit rate on the icache
is something like 50%.  The reason for external caches is probably
to speed up data accesses, which otherwise would go at main memory speeds.

> >P.S. Both Altos and Charles River Data had both the 020 cache and
> >an external 8K cache, Dual did not. Anyone know why?
Dual probably wanted to build a cheaper system.  Depending on the hit
rate and timings, a cache system may LOSE performance because it takes
longer to do a cache miss in a cached system than it takes to do a
memory access in a noncache system.  Remember, performance with a cache
= (hitrate*hitspeed) + ((1-hitrate)*missspeed).  What you buy in
hitspeed may not reclaim all that you lose in missspeed.