From owner-cvs-src@FreeBSD.ORG Mon Feb 16 13:46:02 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 4069016A4CE; Mon, 16 Feb 2004 13:46:02 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3954943D2F; Mon, 16 Feb 2004 13:46:02 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 2BF705C78A; Mon, 16 Feb 2004 13:46:02 -0800 (PST) Date: Mon, 16 Feb 2004 22:46:02 +0100 From: Maxime Henrion To: "M. Warner Losh" Message-ID: <20040216214602.GD35475@elvis.mu.org> References: <28938.1076959003@critter.freebsd.dk> <20040216210503.GC35475@elvis.mu.org> <20040216.142540.32721629.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040216.142540.32721629.imp@bsdimp.com> User-Agent: Mutt/1.4.1i 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:46:02 -0000 M. Warner Losh wrote: > 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. 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. Cheers, Maxime