Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site loral.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!ittatc!dcdwest!sdcsvax!sdcc3!sdcc6!loral!jvz
From: jvz@loral.UUCP (John Van Zandt)
Newsgroups: net.arch
Subject: Re: Cache revisited
Message-ID: <901@loral.UUCP>
Date: Fri, 26-Jul-85 15:44:04 EDT
Article-I.D.: loral.901
Posted: Fri Jul 26 15:44:04 1985
Date-Received: Fri, 2-Aug-85 21:42:38 EDT
References: <5374@fortune.UUCP>
Reply-To: jvz@loral.UUCP (John Van Zandt)
Distribution: net
Organization: Loral Instrumentation, San Diego
Lines: 63

In article <5374@fortune.UUCP> wall@fortune.UUCP (Jim Wall) writes:
>
>    I have a feeling that this topic may once again start the
>religious wars of cache types and implimentations, but just maybe 
>I can get the info that I'm looking for.  Given a multiuser 
>UNIX environment, and given a cache that is split so that user
>and supervisor/kernal are separate; what kind of performance 
>improvment will the cache yield. More information: The cache is
>a simple direct mapped implimentation, as the CPU fetches something
>from RAM (I/O is not cached obviously), it is stored in the cache.
>If that physical address is ever used again, the data will come from
>the cache. 
>
>    So where this will aid in is program loops, and often used 
>routines. The cache is 16K bytes split into 8K for user and 8K for
>supervisor. THE QUESTION IS:  in UNIX how much improvement can the 
>cache make? Let's face it, you won't be making a 70% - 90% hit rate.

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.  However, you haven't given enough information
to determine the performance improvement.  All that a cache can do is
to improve the memory performance for the system.  The standard formula
for computing the speedup looks at the percentage of cache hits times the
cache speed plus the percentage of cache misses times the memory speed.

And there are tricks that effect performance such as the number of cache
sets, whether the cache has a 'dirty' bit, etc.  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.

>
>   O.K., an extra credit part to the problem: 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.

>P.S. Both Altos and Charles River Data had both the 020 cache and
>an external 8K cache, Dual did not. Anyone know why? Not that I'm 
>trying to have someone else do my design work, I believe that for the
>external cache to be really useful, the system architecture must be
>designed for the cache, such as 64 bit wide memory, or block transfers
>on cache misses. Does CRD or Altos do any of these?

I don't agree with the 'designed for the cache' statement, but agree that
you can get slightly better performance if you have designed the memory system
to work with a cache... but the percentage improvement I suspect would
be quite small, and only worthwhile in very high performance systems.

   John Van Zandt
   Loral Instrumentation
   (619) 560-5888

   uucp: ucbvax!sdcsvax!jvz
   arpa: jvz@UCSD

P.S. Of course, the above are my opinions alone and not necessarily those
     of my employer's.