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: <27800032@uiucdcs.UUCP>
Date: Thu, 8-Nov-84 12:05:00 EST
Article-I.D.: uiucdcs.27800032
Posted: Thu Nov  8 12:05:00 1984
Date-Received: Sat, 10-Nov-84 09:26:03 EST
References: <4021@decwrl.UUCP>
Lines: 23
Nf-ID: #R:decwrl:-402100:uiucdcs:27800032:000:1249
Nf-From: uiucdcs!bcase    Nov  8 11:05:00 1984

/* Written  7:50 am  Nov  7, 1984 by kissell@flairvax in uiucdcs:net.arch */
>						And the software time
> spent invalidating the cache it absolutely of no conern here:  one
> cycle (instruction?).  Even a more expensive cache built out of TI's
> 2150 tag buffer chips would still only require one cycle to invalidate
> (assuming, as has been stated, that the cache keys on virtual addresses).

The price paid for purging a virtual-address cache when the virtual map
changes is not so much in the overhead of the act of purging itself, but 
in the loss of those cache lines that otherwise would have remained valid 
and thus been available for use when the pre-purge context was restored.
This can be significant in systems with large caches and frequent context
switches.
/* End of text from uiucdcs:net.arch */

Perfectly true, but this should not be considered a *SOFTWARE* (look at
the original wording) overhead; to me, software overhead is constituted
by such things as trying to decided when to invalidate caches, page
table entries in the TLB, and then actually performing the operation.
Accordingly, I was pointing out that in modern systems a full invalidation
costs only one cycle, as opposed to one cycle per entry as in older
systems.