Date: Wed, 23 Jul 2003 18:52:12 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: brooks@one-eyed-alien.net Cc: gabor@vmunix.com Subject: Re: malloc does not return null when out of memory Message-ID: <200307240152.h6O1qCM7053256@gw.catspoiler.org> In-Reply-To: <20030723224436.GD22166@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Jul, Brooks Davis wrote: > On Thu, Jul 24, 2003 at 12:36:54AM +0200, Matthias Buelow wrote: >> Barney Wolff writes: >> >> >One might argue that this is a config error, and ulimit should be used >> >to cut the address space to below actually available memory. >> >> Wasn't there a sysctl flag to enable/disable overcommitting? >> I think I remember something but I can't find it; it might >> not have been on FreeBSD. > > 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. I think it's a pain in the ass when swap runs out and the kernel decides to kill off my X11 server to fix the problem. In addition to losing everything I'm working on, it also hoses the console. The only reason that I can avoid having to hit the reset switch and risking further system damage is that I have another machine that I can ssh in from to do a clean shutdown. I used SunOS 4.x, which did not overcommit, for many years. Its typical failure mode when swap was exhausted is that large processes would get a error when they attempted to fork() and large memory alloction requests would fail. Everything else would generally keep working because smaller memory allocation requests would still succeed. This usually gave me enough time to take corrective action (generally by cleaning up junk files in /tmp which was a tmpfs mount).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307240152.h6O1qCM7053256>