Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ll-xn!ames!sdcsvax!celerity!ps
From: ps@celerity.UUCP (Pat Shanahan)
Newsgroups: comp.arch
Subject: Re: Phys vs Virtual Addr Caches
Message-ID: <227@celerity.UUCP>
Date: Thu, 16-Jul-87 12:14:06 EDT
Article-I.D.: celerity.227
Posted: Thu Jul 16 12:14:06 1987
Date-Received: Sat, 18-Jul-87 08:11:47 EDT
References: <3904@spool.WISC.EDU>
Reply-To: ps@celerity.UUCP (Pat Shanahan)
Organization: Celerity Computing, San Diego, Ca.
Lines: 40

In article <3904@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes:
>Here's a question.  Why do people build their caches to respond to physical
>addresses instead of virtual addresses?  Another way to state the question
>is: why not put the VM -> PM translation logic next to (in parallel with)
>the data cache, rather than before it?
>
...
>
>Larry McVoy 	        lm@cottage.wisc.edu  or  uwvax!mcvoy


Virtual address caches are limited in their applications, because of the
difficulty in maintaining consistency. It is possible for a single item of
data to have several different addresses. For example, an area of System V
style shared memory can be attached at different virtual addresses by
different processes. If the system either has multiple caches, or does not
purge the cache on context switch, the same shared data can be in the cache
system with several different virtual addresses in different address spaces.

Suppose one of the processes modifies the data. The system has to ensure
that all cache copies of that data are either deleted or updated. If the
cache is real-addressed this is relatively easy.  If it is virtual addressed
the system has the problem of determining all the addresses the data might
have.

There is also a minor difficulty with using virtual addresses for caches
that are not purged on context switch. The virtual address has to be
extended by appending some form of context identifier so that equal virtual
addresses in different address spaces will not be confused.

Virtual addressed caches can work very well, for example for instruction
caches. Instruction modification is a much rarer event than data
modification and can be handled by doing general purges rather than purging
only the specific item.

-- 
	ps
	(Pat Shanahan)
	uucp : {decvax!ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ps
	arpa : sdcsvax!celerity!ps@nosc