Date: Mon, 16 Feb 2004 14:25:40 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: mux@FreeBSD.org Cc: des@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_kern.c Message-ID: <20040216.142540.32721629.imp@bsdimp.com> In-Reply-To: <20040216210503.GC35475@elvis.mu.org> References: <Pine.NEB.3.96L.1040216140303.63057O-100000@fledge.watson.org> <28938.1076959003@critter.freebsd.dk> <20040216210503.GC35475@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040216210503.GC35475@elvis.mu.org>
Maxime Henrion <mux@FreeBSD.org> writes:
: Poul-Henning Kamp wrote:
: > In message <Pine.NEB.3.96L.1040216140303.63057O-100000@fledge.watson.org>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040216.142540.32721629.imp>