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