From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 18:52:32 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DE7837B401 for ; Wed, 23 Jul 2003 18:52:32 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A47EB43F85 for ; Wed, 23 Jul 2003 18:52:31 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9/8.12.9) with ESMTP id h6O1qCM7053256; Wed, 23 Jul 2003 18:52:15 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200307240152.h6O1qCM7053256@gw.catspoiler.org> Date: Wed, 23 Jul 2003 18:52:12 -0700 (PDT) From: Don Lewis To: brooks@one-eyed-alien.net In-Reply-To: <20030723224436.GD22166@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: mkb@mukappabeta.de cc: barney@databus.com cc: freebsd-stable@FreeBSD.org cc: gabor@vmunix.com Subject: Re: malloc does not return null when out of memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2003 01:52:32 -0000 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).