cvs commit: src/sys/vm vm_kern.c

[M. Warner Losh]

In message: <20040216210503.GC35475 at elvis.mu.org>
            Maxime Henrion <mux at FreeBSD.org> writes:
: Poul-Henning Kamp wrote:
: > In message <Pine.NEB.3.96L.1040216140303.63057O-100000 at 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