davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (05/03/90)
In article <292@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes: | In article <883@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) write| >In article <332@hub.cs.jmu.edu> arch@hub.cs.jmu.edu (Arch Harris) writes: | > I believe there are, but my personal experience is that over 64k you | >hit diminishing returns (actually 32k does a lot). | | This fits with some tables Intel published on various cache organizations | and sizes, and with my experience. However, the data also makes it clear | that organization makes a big difference too, that is 32k 4way set-assoc. | could end up about the same hit rates as 128k direct mapped (I don't have | the data in front of me, but I remember that set-assoc. buys you quite | a bit). Also, keep in mind that those last few pecent of hit rate can | make a big difference if the main memory is very slow. A good point. I stand clarified if not actually corrected. Something which has 95% hit instead of 90% goes to main memory only half as much. Now the question is, what does that cost in terms of wait states? That's very machine dependent, but let's assume two. Then, 0.90 * 2w/s + 0.10 * 4w/s = 2.2w/s (effective) 0.95 * 2w/s + 0.05 * 4w/s = 2.1w/s A gain of 5%. If you assume 6w/s (slow but not unheard of) 0.90 * 2w/s + 0.10 * 6w/s = 2.50 0.95 * 2w/s + 0.05 * 6w/s = 2.20 A gain of 12%. Finally, if you assume 6w/s and 16 bit memory (yecch) 0.90 * 2w/s + 0.10 * 12w/s = 3.00 0.95 * 2w/s + 0.05 * 12w/s = 2.50 A gain of 17%. If you make the main memory slow enough you can justify a lot of cahce, and be making a good decision. I think the last case is pretty unlikely, but I'm told that you can get 12 clock access with 32 bit memory on access to non-interleaved memory. The question then gets cloudier when you consider that doubling the cache size doesn't double the hit rate (or more accurately halve the miss rate) for most loads. So while it's probably true to say that more cache or faster memory will always make your system faster, it's not true that any kind of memory will always be the most cost effective improvement to a system. Maybe adding an FPU or a better disk controller will do more. People are still getting master's theses from this, so we're not going to solve it in a screen or two. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
mat@zeus.opt-sci.arizona.edu (Mat Watson) (05/03/90)
I've been following this thread about cache hits with some interest, and I'd like to ask you guys a couple questions: Since *nix swaps entire jobs ( which I assume are larger than the cache ), doesn't that screw up the hit rate? And: What makes the Logix board without cache different from other boards without cache? --Mat mat@zeus.opt-sci.arizona.edu [128.196.128.219] ...{allegra,cmcl2,hao!noao}!arizona!zeus.opt-sci.arizona.edu!mat Optical Sciences Center, Univ. of Arizona, Tucson, AZ 85721, USA
mat@zeus.opt-sci.arizona.edu (Mat Watson) (05/03/90)
I've gotten some responses to my posting, and I STAND CORRECTED! Thanks for setting me straight. I wrote: > Since *nix swaps entire jobs ( which I assume are larger than the > cache ), doesn't that screw up the hit rate? Not True. I'm told that Unix seldom swaps out entire jobs, so the cache actually ends up working pretty well on a single user system. --Mat
paul@dialogic.com (The Imaginative Moron aka Joey Pheromone) (05/03/90)
In article <MAT.90May2214726@zeus.megaron.arizona.edu> mat@zeus.opt-sci.arizona.edu (Mat Watson) writes: > >Since *nix swaps entire jobs ( which I assume are larger than the >cache ), doesn't that screw up the hit rate? False premise. Unix V/386 rel 3 is primarily demand paged. It *does* swap complete jobs, but only under peculiar circumstances and great duress. The prime memory managment scheme is demand paging. -- Paul Bennett | | "I give in, to sin, because Dialogic Corp. | paul@dialogic.UUCP | You have to make this life 300 Littleton Road | ..!uunet!dialogic!paul | livable" Parsippany, NJ 07054 | | Martin Gore
dwc@cbnewsh.ATT.COM (Malaclypse the Elder) (05/04/90)
In article <MAT.90May3084057@zeus.megargon.arizona.edu>, mat@zeus.opt-sci.arizona.edu (Mat Watson) writes: > I've gotten some responses to my posting, and > I STAND CORRECTED! Thanks for setting me straight. > > I wrote: > > Since *nix swaps entire jobs ( which I assume are larger than the > > cache ), doesn't that screw up the hit rate? > > Not True. I'm told that Unix seldom swaps out entire jobs, > so the cache actually ends up working pretty well on a single > user system. > actually, if you consider process switches instead of swaps, then you have a point. if the cache is a virtual one, then process switches will result in cache flushes (unless there is a process id tag in the cache). if the cache is a physical one, then you don't have to worry unless there is either a process swap, a page replacement, or a process exit. but in this case, you are sharing your 64K cache (or whatever size) with other processes. danny chen att!hocus!dwc
pb@idca.tds.PHILIPS.nl (Peter Brouwer) (05/04/90)
In article <MAT.90May3084057@zeus.megargon.arizona.edu> mat@zeus.opt-sci.arizona.edu (Mat Watson) writes: >I've gotten some responses to my posting, and >I STAND CORRECTED! Thanks for setting me straight. >I wrote: >> Since *nix swaps entire jobs ( which I assume are larger than the >> cache ), doesn't that screw up the hit rate? >Not True. I'm told that Unix seldom swaps out entire jobs, >so the cache actually ends up working pretty well on a single >user system. > In a paging system pages are loaded on demand and if memory gets thight pages are swapped. If a page is swapped out or in it is copied through a few buffers in memory in the kernel code. Like from the memory from the disk controller into a kernel buffer and from that to the location in memory where it will be used. Does this not trash the cache? -- Peter Brouwer, # Philips Information Systems, NET : pb@idca.tds.philips.nl # Department SSP-P9000 Building V2, UUCP : ....!mcsun!philapd!pb # P.O.Box 245, 7300AE Apeldoorn, The Netherlands. PHONE:ext [+31] [0]55 432523, #
rcd@ico.isc.com (Dick Dunn) (05/05/90)
dwc@cbnewsh.ATT.COM (Malaclypse the Elder) writes: > ...if the cache is a virtual one, then > process switches will result in cache flushes (unless there > is a process id tag in the cache). if the cache is a physical > one, then you don't have to worry unless there is either a > process swap, a page replacement, or a process exit. but in > this case, you are sharing your 64K cache (or whatever size) > with other processes. Caches on 386 systems are, of necessity, physical-address caches: The virtual-to-physical mapping happens on-chip; the processor presents a physical address on the pins. The case of process exit doesn't matter directly, since the pages are just freed. It will matter when a frame (or whatever you want to call it, the physical-memory container for a page) is reassigned. Process-swap and page-replacement also come down to the same thing: You have to do some- thing when you reassign physical memory. This just means that the cache has to know (or be told) when memory locations are modified. It knows about CPU accesses, of course; it's DMA that it has to worry about. As for sharing the cache, yes, that's an issue. The interesting questions have to do with how many active processes you've got, how often you allow switching among them, and how much active memory you've got in each process. Although we lament how programs seem to be growing without bound, the most active areas in programs still tend to stay small. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Lately it occurs to me what a long, strange trip it's been.
rcd@ico.isc.com (Dick Dunn) (05/05/90)
pb@idca.tds.PHILIPS.nl (Peter Brouwer) writes: > In a paging system pages are loaded on demand and if memory gets thight > pages are swapped. This is a confusion of terms. "Paging" refers to movement of individual pages from a process. To avoid confusion, the process of cleaning a page-- that is, writing out the contents of a modified page frame so that it can be reused to "page in" something else--is normally called a "pageout". That way, "swapping" can be used to refer to wholesale movement of processes in/out of memory: When memory commitment gets too high, you can "swap out" a process--meaning to remove ALL of its pages from physical memory. > If a page is swapped out or in it is copied through a few buffers in memory > in the kernel code. Like from the memory from the disk controller into a > kernel buffer and from that to the location in memory where it will be used. No, pages don't go through the buffer cache. The page goes, in effect, between the disk controller (which, although it may be "memory", is not system memory and is not subject to the main memory-system caching) and the physical memory where it belongs. Thus this only affects caching to the extent that bringing in a page replaces any cached locations for that page--which is just what you want. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Lately it occurs to me what a long, strange trip it's been.