Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!iuvax!rutgers!att!cbnewsh!dwc From: dwc@cbnewsh.ATT.COM (Malaclypse the Elder) Newsgroups: comp.unix.i386 Subject: Re: 386 Motherboards Message-ID: <10077@cbnewsh.ATT.COM> Date: 3 May 90 22:29:53 GMT References: <15966@cbnews.ATT.COM> <332@hub.cs.jmu.edu> <883@sixhub.UUCP> Organization: The Legion of Dynamic Discord Lines: 23 In article , 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