Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!utah-morgan!hellgate.utah.edu!jaguar.cs.utah.edu!mike From: mike%jaguar.cs.utah.edu@cs.utah.edu (Mike Hibler) Subject: Re: BSD44 on a SPARC questions Date: 17 Nov 93 14:22:40 MST Message-ID: <1993Nov17.142240.29038@hellgate.utah.edu> Organization: University of Utah Computer Science References: <35396@dog.ee.lbl.gov> <CGCCLz.pL2@austin.ibm.com> <35439@dog.ee.lbl.gov> Lines: 19 In article <35439@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes: >In article <CGCCLz.pL2@austin.ibm.com> roger@wizards.austin.ibm.com >(Roger Florkowski) writes: >>[hang with 8 MB] > >The Mach 2.5 VM, as adapted into BSD, is prone to hangs. There may >also be an as-yet-undiscovered race somewhere in the sparc code. > It is actually the Mach 2.0 VM, but yes, as implemented in BSD there are no limit checks when allocating VM (other than the per-process rlimits). So once you have allocated more than your swap + physmem it will eventually lock up when it can't page out anything (due to lack of swap) and hence can't page in anything new. This reflects the "its just a prototype, I'll take care of that later" heritage of the VM code (where "later" never came). As for the swap_pager printf, just set swpagerdebug to 0. It was originally set to detect anomalous conditions that I wasn't expecting to see on my machine and that might indicate races or resource leaks.