Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!olivea!charnel!xmission!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.development Subject: Re: Notes on the *new* FreeBSD V1.1 VM system Date: 22 Feb 1994 23:18:52 GMT Organization: Weber State University, Ogden, UT Lines: 23 Message-ID: <2ke3ss$l0d@u.cc.utah.edu> References: <BcxpGux.dysonj@delphi.com> <MYCROFT.94Feb20102534@duality.gnu.ai.mit.edu> <CLL9J6.FCF@endicor.com> NNTP-Posting-Host: cs.weber.edu In article <CLL9J6.FCF@endicor.com> tsarna@endicor.com (Ty Sarna) writes: >Is there any reason why memory allocation can't simply fail when there >isn't any more to allocate? Sure, lots of unix software is going to >kill itself off anyway dereferencing NULL pointers, but it at least >gives those who care to check return values a chance to avoid >catastrophe. This is an inevitable consequence of any system that does memory overcommit (thus allowing you to run more processes than you are allowed to run). I occasionally rail about the evils of memory overcommit, but in the end I am usually shouted down (mostly by people who don't want to spend the extra disk required for swap space). Personally, I think you should be required to rebuild a kernel with "option FAST_AND_LOOSE" if you want overcommit enabled. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.