Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!cmcl2!phri!roy From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.arch Subject: Re: Phys vs Virtual Addr Caches Message-ID: <2798@phri.UUCP> Date: Thu, 16-Jul-87 20:22:22 EDT Article-I.D.: phri.2798 Posted: Thu Jul 16 20:22:22 1987 Date-Received: Sat, 18-Jul-87 09:06:09 EDT References: <3904@spool.WISC.EDU> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 27 In article <3904@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes: > Why do people build their caches to respond to physical addresses instead > of virtual addresses? The scheme Larry describes sure sounds like it would be a win but for one problem. How do you deal with invalidating cache lines when some DMA I/O device writes into the corresponding main memory location? The I/O device is generating physical addresses but the cache is keying on virtual addresses. Now that I've posed the problem, I'll throw out some possible answers. 1) When you store to cache, install VA as the key and store the PA along with the data. CPU-generated addresses key on VA, I/O generated addresses key on PA for purposes of invalidation. Makes the cache wider and adds more key-match logic. 2) Do I/O with VA's instead of PA's and have DMA go through the VM machinery. Doesn't make the I/O device any more complicated to build (in fact, doesn't change it one whit) but adds more complexity to the I/O bus adaptor. Add to all this the fact that you can (and very well might want to) have multiple VA's mapping to the same PA. Nasty wrinkle all around. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016