From owner-cvs-all@FreeBSD.ORG Tue Feb 17 01:05:25 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A1AE16A4CE; Tue, 17 Feb 2004 01:05:25 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9741643D39; Tue, 17 Feb 2004 01:03:24 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i1H93NLE015311; Tue, 17 Feb 2004 20:03:23 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i1H91Jch003343; Tue, 17 Feb 2004 20:01:20 +1100 Date: Tue, 17 Feb 2004 20:01:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Maxime Henrion In-Reply-To: <20040216214602.GD35475@elvis.mu.org> Message-ID: <20040217195303.X16798@gamplex.bde.org> References: <20040216210503.GC35475@elvis.mu.org> <20040216214602.GD35475@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: scottl@FreeBSD.org cc: cvs-all@FreeBSD.org cc: phk@phk.freebsd.dk cc: rwatson@FreeBSD.org cc: "M. Warner Losh" cc: des@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_kern.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 09:05:25 -0000 On Mon, 16 Feb 2004, Maxime Henrion wrote: > M. Warner Losh wrote: > > In message: <20040216210503.GC35475@elvis.mu.org> > > Maxime Henrion writes: > > : I find it very convenient to have a flag to tell malloc() to try as hard > > : as it can to allocate the memory without crashing on us. I suspect this > > : could allow us to remove a fair number of kernel compile-time options. > > : > > : The patch can be found at http://www.mu.org/~mux/patches/malloc.patch. > > > > How would that be different than M_NOWAIT and then trying again a > > couple of times? Each time will fail if it is too big. And that's > > not meaningfully distinguishable from there not being enough memory > > currently available to satisfy the request. > > Because if there is a memory shortage but it's possible to get the > requested amount of memory later (because it's smaller than kmem_map), > M_WAITOK | M_SAFE won't fail but wait while M_NOWAIT will fail right > away. Why trying again when we already have a flag for this? What this > patch does is allow to call malloc(verybignumber) without crashing to > help in cases where it's hard to define what's a reasonable size. I think malloc(verybignumber) shouldn't be encouraged, since it might succeed and consume almost all malloc'able memory, and then other requests for relatively small amounts of memory will fail. Callers that want lots of memory should be careful not to ask for more than they need and can reasnbly expect to get. Bruce