From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 19:31:00 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 90E4D37B401 for ; Wed, 23 Jul 2003 19:31:00 -0700 (PDT) Received: from altair.mukappabeta.net (p3E9BE28C.dip.t-dialin.net [62.155.226.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B5843F85 for ; Wed, 23 Jul 2003 19:30:58 -0700 (PDT) (envelope-from mkb@mukappabeta.de) Received: from mukappabeta.de (localhost [127.0.0.1]) by altair.mukappabeta.net (Postfix) with ESMTP id 8F71F5959 for ; Thu, 24 Jul 2003 04:35:14 +0200 (CEST) Message-ID: <3F1F45E2.5080506@mukappabeta.de> Date: Thu, 24 Jul 2003 04:35:14 +0200 From: Matthias Buelow Organization: GeFoekoM e.V. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030504 X-Accept-Language: de-de, de, en-gb, en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org 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> <20030724021726.GJ430@gsmx07.alcatel.com.au> In-Reply-To: <20030724021726.GJ430@gsmx07.alcatel.com.au> X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 02:31:00 -0000 Peter Jeremy wrote: > FreeBSD behaviour in the face of swap shortage is a regular and > popular discussion topic. I suggest that a perusal of the archives > will probably answer any questions. If anyone wishes to suggest a > "solution" to FreeBSD's behaviour when there is a shortage of swap, > please include patches. What makes me ask the following (note that it's neither a flame, nor a suggestion). Does FreeBSD actually account the used swap/vm so far (it needn't since it doesn't guarantee that it'll be available, with overcommit) or does it not do that (i.e., it has no idea of how much vm was requested by all processes so far, without having to go through the maps of all processes, of course)? And is it planned in the (distant) future to add a knob to toggle overcommitting of swap? While with large disks and hence swap sizes this probably isn't a pressing problem for most applications, it might be nice to be able to control the system not to randomly kill off applications or force the user to meticulously plan and calculate memory load of the planned application zoo in order to tune the ulimits of various memory-hungry processes in a way that they'll all fit into swap in the worst case situation. -- Matthias Buelow; mkb@{mukappabeta.de,informatik.uni-wuerzburg.de}