Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!dptspd!ephsa!endicor.com!tsarna From: tsarna@endicor.com (Ty Sarna) Newsgroups: comp.os.386bsd.development Subject: Re: Notes on the *new* FreeBSD V1.1 VM system Message-ID: <CLL9J6.FCF@endicor.com> Date: 21 Feb 94 19:16:17 GMT References: <BcxpGux.dysonj@delphi.com> <MYCROFT.94Feb20102534@duality.gnu.ai.mit.edu> Organization: Endicor Technologies, Inc., San Antonio, Texas Lines: 27 In article <MYCROFT.94Feb20102534@duality.gnu.ai.mit.edu> mycroft@duality.gnu.ai.mit.edu (Charles Hannum) writes: > > mentions have been addressed in NetBSD already. Except for the > behavior when paging space runs out (which is a subject of debate; > several Mach-based systems simply panic, while others algorithmically > choose processes to kill), there are no reported instabilities in the > NetBSD VM system. IMHO, each of these behaviors is almost equally unpallatable. If I'm running an important process (say a long-running memory-hungry application such as ray-tracing, database server, or whatever), and the system decides to kill it arbitrarily, it might as well have paniced as far as I'm concerned. In either case, my processes get killed with no warning or chance to avoid it. AIX implemented the killing behavior, and there were so many complaints from customers (database servers getting killed and corrupting the database, etc) that I believe they finally changed it. 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. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa."