[net.arch] not missing anything

dan@pyramid.UUCP (03/08/86)

>
>...  The space that is freed up on a RISC chip by having
>little if any u-code ROM can be used for more cache.  ...
>... So, having the cache effectively reduces Bus traffic not only to a CISC
>level (because of above explanation) but also probably LESS traffic because
>the cache can be used for ALL instructions (and data).
>Or am I missing something?
>
berger@imag.UUCP (Gilles BERGER SABBATEL) replys:
>OK, but what when the system is multiprogrammed? Frequent swaps between
>processes aren't likely to break the cache efficiency?   This could be
>the cause of important degradation of RISC performance in multiuser
>environment (Cf previous discussions about the Ridge).
>
>... Or am I missing something?....

First of all, the problem of multiprogramming effects on caches are common
to ANY cached machine (RISC or CISC or whatever).  Secondly, (as far as
'defending' caches) the problem can be reduced greatly: (1) the on-chip
cache is not likely to be that large.  Even if we flushed the entire on-chip
cache after every context switch, it wouldn't be any big deal (how often
are users switched anyway? Couldn't be more than a few hundred times a
second).  (2) in slightly more elaborate schemes (commonly used for large
off-chip caches) each cache line's TAG could contain the entire process
ID and other info, so that a context switch would not require flushing
of the cache.  Of course, dilution still occurs because of the room the
old (say, 'context A') cache lines occupied, but in many cases, after
switching back to context A (from wherever) many of those lines will still
be there!! Indeed, the more frequent the context switches , the more likely
it is that those lines will be there, somewhat negating the other degradations
due to switches.
Please please not let me be missing something!!!!!!!!!!!!!!!!!! :-)


-- 


  'Out of the inkwell comes Bozo the Clown ...'
 
DISCLAIMER:  These opinions are neither mine nor my C-compiler's
       sun!pyramid!dan

darrell@sdcsvax.UUCP (Darrell Long) (03/12/86)

In article <145@pyramid.UUCP> dan@.UUCP (Dan Sobottka) writes:
>
>First of all, the problem of multiprogramming effects on caches are common
>to ANY cached machine (RISC or CISC or whatever).  Secondly, (as far as
>'defending' caches) the problem can be reduced greatly: (1) the on-chip
>cache is not likely to be that large.  Even if we flushed the entire on-chip
>cache after every context switch, it wouldn't be any big deal (how often
>are users switched anyway? Couldn't be more than a few hundred times a
>second).  (2) in slightly more elaborate schemes (commonly used for large
>off-chip caches) each cache line's TAG could contain the entire process
>ID and other info, so that a context switch would not require flushing
>of the cache.  Of course, dilution still occurs because of the room the
>old (say, 'context A') cache lines occupied, but in many cases, after
>switching back to context A (from wherever) many of those lines will still
>be there!! Indeed, the more frequent the context switches , the more likely
>it is that those lines will be there, somewhat negating the other degradations
>due to switches.
>Please please not let me be missing something!!!!!!!!!!!!!!!!!! :-)
>
>       sun!pyramid!dan

I must be missing something!  If you are caching PHYSICAL addresses,
I do not see any reason to flush the cache.  In a virtual memory
system then the TLB must be flushed since it contains virtual addresses,
but the cache should not have to be flushed (in a base & bound register
environment the physical address could be compared to the bound register
to prevent illegal access).
-- 
Darrell Long
Department of Electrical Engineering and Computer Science
University of California, San Diego

UUCP: sdcsvax!darrell
ARPA: darrell@sdcsvax