Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.6.2.17 $; site uiucdcs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!inuxc!pur-ee!uiucdcs!bcase
From: bcase@uiucdcs.UUCP
Newsgroups: net.arch
Subject: Re: 68020 Performance Revisited after re
Message-ID: <27800030@uiucdcs.UUCP>
Date: Mon, 5-Nov-84 19:40:00 EST
Article-I.D.: uiucdcs.27800030
Posted: Mon Nov  5 19:40:00 1984
Date-Received: Wed, 7-Nov-84 06:35:33 EST
References: <4021@decwrl.UUCP>
Lines: 23
Nf-ID: #R:decwrl:-402100:uiucdcs:27800030:000:1090
Nf-From: uiucdcs!bcase    Nov  5 18:40:00 1984

> > Falcone is setting up something of a "straw man" here.  A conscientious
> > 68020 design MUST use a data cache, and the data cache keys must be
> > VIRTUAL addresses.  
> 
> Whether the cache should be virtual or real-address based would seem to 
> me to depend on a tradeoff between burning an MMU cycle for every access
> (real-address cache) and purging the cache every time the virtual map
> changes (virtual-address cache).
> 
> Kevin D. Kissell

That is correct, and it is generally agreed (at least among people I know,
and apparently among a lot of system designers) that burning an MMU cycle
on every memory reference is much worse for performance in general than
purging the (possibly only user partition of the) cache tags on process
switches.  Slowing cache accesses down from one to two cycles is a 100%
increase while causing a little extra cache refilling due to cold start
conditions in only a marginal percentage overhead, on the average (since
process switches occur (much) less than 200 times a second most of the
time, especially in single user systems).

    bcase