Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!husc6!cs.utexas.edu!loyola!ross!doug
From: doug@ross.UUCP (doug carmean)
Newsgroups: comp.arch
Subject: Re: i860 CPU information
Message-ID: <222@ross.UUCP>
Date: 15 Mar 89 14:42:49 GMT
References: <1895@oakhill.UUCP> <21570@shemp.CS.UCLA.EDU> <3024@alliant.Alliant.COM>
Reply-To: doug@ross.UUCP (doug carmean)
Organization: ROSS Technology. Austin, TX
Lines: 48


In article  <21923@lll-winken.LLNL.GOV> brooks@maddog.llnl.gov (Eugene Brooks) writes:
>Although you don't count flushing the D-cache as a viable answer, for
>large scalable multiprocessor systems such a solution is indeed viable.
>In particular, if you are not talking about a bus architecture at all
>where snooing is not very easy to do,  write-through caches which
>use the volatile keyword in C as a mechanism to force a cache miss
>on a read are quite useful.  Non-bus systems don't have a memory
>bandwidth problem, they generally have a memory latency problem.
.
It seems to me that you are proposing a multiprocessing system that 
implements a cache but never actually uses the cache.  Your cache 
scheme uses write through and then forces misses on the reads.  Why
even bother implementing a D-cache?
.
>This is of course somewhat of a tangent to the issue for the i860.
>The i860's cache is not write-through with explicit user code
>management of the cache lines so it does not fit in the "non-bus"
>scheme mentioned above very well, and the current on chip cache
>does not have a coherence strategy useful for bus based shared
>memory multiprocessors (other than to keep shared data out of the
>on chip cache).  For such a small on chip cache the "flush
>the cache on a context switch" is not really much of an issue. 
.
I think what you really mean here is that using such a cache system
in an application with heavy context switching is not really much
of an issue - you would never want to do it!  From what I understand
of the i860, you must flush the I-cache, the D-cache and the TLB on
a context switch.  This seems like a very big penalty to pay every
single time you want to switch contexts.
.
>I suspect that you have to do this anyway for a single cpu machine
>as the cache is a virtual memory cache.
.
A virtual memory cache does not necessarily imply that you must flush
the cache on every context switch.  An easy solution to this problem
is to store the context number along with the cache tag entry.  This
way the context number is compared along with the tag entry to 
determine if a chache entry is a hit or not.  Also note that there
are alternative solutions to vitual caches in a multiprocessing system
other than the solution you have presented here.  A virtual cache 
that implements a copyback scheme with bus snooping is very
feasible in a multprocessing environment.

-- 
-doug carmean
-ROSS Technology, 7748 Hwy 290 West Suite 400, Austin, TX 78736
-ross!doug@cs.utexas.edu