Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP
Path: utzoo!utcsri!garfield!hammond@petrus.UUCP (Rich A. Hammond)
From: hammond@petrus.UUCP (Rich A. Hammond)
Newsgroups: net.arch
Subject: Re: Re: Cache revisited + page tables
Message-ID: <3772@garfield.UUCP>
Date: Wed, 9-Oct-85 17:50:14 EDT
Article-I.D.: garfield.3772
Posted: Wed Oct  9 17:50:14 1985
Date-Received: Wed, 9-Oct-85 21:45:32 EDT
References: <5374@fortune.UUCP> <901@loral.UUCP> <2583@sun.uucp> <37@intelca.UUCP>
Sender: news@garfield.UUCP
Distribution: net
Organization: Memorial U. of Nfld. C.S. Dept., St. John's
Lines: 39

On cache's:  The hit rates reported are published in the literature, try
ACM's Transactions on Computer Systems for several articles on the DEC VAX
performance measurements. (TOCS isn't that old, you can check all the issues.)
Another publication would be Computer Architecture News, particlarly the
annual Computer Architecture Conference proceedings.  When I get to my office
I'll try and get the exact issues.

Multi-way set associative caches are implemented on some machines, I suspect
that the performance gain drops off after 2 to 4 sets.  Keeping separate
User/Supervisor caches works better in a multi-user operating system,
since one user doesn't wipe out the cache for everyone and frequently
occuring system things (like serial line interrupt code, maybe) stay in cache.
Similarly, split instruction/data caches are simpler to build than a multi-
way set associative cache but are better than a single cache for both.

> Ken Shoemaker asks:
> One more thing, doesn't putting all the page tables in dedicated memory:
> 
> 	1) waste lots of high-speed expensive memory
> 	2) limit the virtual memory size of processes
> 
> Maybe this wasn't a problem with 68010s, since they only had 24 address
> bits, but with 68020s, I would think it a problem, especially if
> someone wants to do something as foolish as direct file mapping
> onto optical disks.  Any solutions, or do I not understand the gist
> of how these puppies work?

You don't have to keep the page tables in dedicated memory (I assume you
mean fast static RAM), the DEC VAX and the NS32000 family both have caches
of frequently used page table entries and keep the rest in main memory.
The thing I would hope that Motorola does better is allow a larger size
page (VAX and NS320000 use 512 bytes/page).  As dynamic RAM gets less
expensive per bit it makes sense to accept greater internal fragmentation
in pages in return for smaller page tables.  This really works because
user processes tend to keep up in size with available memory, so as
more memory becomes available the user trys things like direct mapping of
large files.

Rich Hammond, Bellcore	[ihnp4, allegra, ucbvax]!bellcore!hammond