Date: Sun, 27 Jul 2003 23:59:27 -0700 From: David Schultz <das@FreeBSD.ORG> To: Matthias Buelow <mkb@mukappabeta.de> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: malloc does not return null when out of memory Message-ID: <20030728065927.GA18154@HAL9000.homeunix.com> In-Reply-To: <20030723230034.GB24008@moghedien.mukappabeta.net> References: <20030723173427.GA72876@vmunix.com> <20030723140329.C92624@carver.gumbysoft.com> <20030723221336.GA26555@pit.databus.com> <20030723223654.GA24008@moghedien.mukappabeta.net> <20030723224436.GD22166@Odin.AC.HMC.Edu> <20030723230034.GB24008@moghedien.mukappabeta.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 24, 2003, Matthias Buelow wrote: > Brooks Davis writes: > > >No there isn't. Overcommit is a fundamental design feature of the BSD > >VM. If you don't like it, find an OS that doesn't do it. The only one > >I can think of off the top of my head in Irix where I've found it to be > >a serious pain in the ass. > > Hmm, I could've sworn that fbsd's got some option to toggle it. > But apparently this is not so, a pity. I'd like to have the choice > between better resource usage (with overcommit enabled) and safer > operation (disabled, when an application won't crash at some random > point because it cannot get mapped memory). FreeBSD has always overcommitted. (In general, most BSD-based systems overcommit and most System V-based systems don't.) The trouble with non-overcommit is that once you account for the stack, shared memory space, etc., you're forced to drastically overestimate the amount of swap required to avoid overcommitting. But these days disk space is cheap, so that argument may not hold much water anymore. Discussion of complicated hacks to work around the fact that we overcommit is probably not useful. For now, we have a simple hack (thanks to Wes) that allows the administrator to designate certain applications as being sacred from the point of view of the pageout daemon's out-of-memory killer. This gives you the benefits of non-overcommit for your important applications, with the caveat that you trust those programs not to eat up all the memory in the system and cause a deadlock. So it's down to a question of who wants to implement non-overcommit. ;-) It isn't as easy as it might seem...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030728065927.GA18154>