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.