Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!sun!idi!intelca!kds
From: kds@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.arch
Subject: Re: Re: Cache revisited + page tables
Message-ID: <37@intelca.UUCP>
Date: Tue, 13-Aug-85 06:19:17 EDT
Article-I.D.: intelca.37
Posted: Tue Aug 13 06:19:17 1985
Date-Received: Sun, 18-Aug-85 23:00:34 EDT
References: <5374@fortune.UUCP> <901@loral.UUCP> <2583@sun.uucp>
Distribution: net
Organization: Intel, Santa Clara, Ca.
Lines: 56

> John Van Zandt of Loral Instrumentation (ucbvax!sdcsvax!jvz) said:
> > Cache's are strange creatures, exactly how they are designed can impact
> > performance significantly.  Your idea of separate cache's for supervisor
> > and user is a good one.
> I believe (uninformed opinion) that this makes it perform worse, all
> other things equal.  It means that at any given time, half the cache
> is unusable, thus if you spend 90% of your time in user state you
> only have a halfsize cache.  (Ditto if you are doing system state stuff.)

I believe (uninformed opinion) that a better solution is to use a
multi-way set associative cache.  Also that the performance enhancement/
degradation is all tied to the amount of time spend bouncing between
user/supervisor mode and the average lifetime of items in the cache.
If you have a large cache (with presumably large hit rates) in a program
that does lots of system calls, you could easily thrash your cache
if it spends all its time updating the same cache cells shared between
the user code and the supervisor code.  A multi-way associative cache
is really the best of both worlds, since it allows both options (a large
non-split cache or two half size split caches), albeit at increased expense...
The same argument could be applied to seperate instruction/data caches.

> is something like 50%.  The reason for external caches is probably
> to speed up data accesses, which otherwise would go at main memory speeds.
> 
> > >P.S. Both Altos and Charles River Data had both the 020 cache and
> > >an external 8K cache, Dual did not. Anyone know why?
> Dual probably wanted to build a cheaper system.  Depending on the hit
> rate and timings, a cache system may LOSE performance because it takes
> longer to do a cache miss in a cached system than it takes to do a
> memory access in a noncache system.  Remember, performance with a cache
> = (hitrate*hitspeed) + ((1-hitrate)*missspeed).  What you buy in
> hitspeed may not reclaim all that you lose in missspeed.

But what is the real story here, i.e., does anyone out there have real
numbers for the systems (or others) mentioned?

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?
-- 
...and I'm sure it wouldn't interest anybody outside of a small circle
of friends...

Ken Shoemaker, Microprocessor Design for a large, Silicon Valley firm

{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
	
---the above views are personal.  They may not represent those of the
	employer of its submitter.