From owner-cvs-src@FreeBSD.ORG Mon Feb 16 13:25:47 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D11416A4CE; Mon, 16 Feb 2004 13:25:47 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1902243D1F; Mon, 16 Feb 2004 13:25:47 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1GLPgnJ004013; Mon, 16 Feb 2004 14:25:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 16 Feb 2004 14:25:40 -0700 (MST) Message-Id: <20040216.142540.32721629.imp@bsdimp.com> To: mux@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20040216210503.GC35475@elvis.mu.org> References: <28938.1076959003@critter.freebsd.dk> <20040216210503.GC35475@elvis.mu.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: des@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_kern.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 21:25:47 -0000 In message: <20040216210503.GC35475@elvis.mu.org> Maxime Henrion writes: : Poul-Henning Kamp wrote: : > In message , Robe : > rt Watson writes: : > : > >It seems like it all comes down to the perfectly reasonable desire to be : > >able to represent the following request: : > > : > > Userspace wants me to allocate some memory. I don't know how large : > > rediculous is, but I don't want to panic when I ask for something : > > rediculous and instead get a failure I can report. : > : > Sounds like we need to add a new flag: M_TELL_ME_IF_I_AM_STUPID : : I suggested an M_SAFE patch for malloc(9) to Dag and did a patch for it : already. The semantics are "return NULL and don't panic if I'm asking : for too much". I find this useful because there are cases where we are : asked to do something by an userland program, via a syscall or something : else, that will require us to allocate X bytes of memory. In those : cases, we generally make the code enforce artificial limits, to prevent : the kernel form panic'ing. It's practically impossible to have : meaningful limits, so we end up having yet another compile-time kernel : option. There is also some code that totally ignores it, probably : because the author didn't know about the panic() in kmem_malloc(). : : 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. Warner