cvs commit: src/sys/vm vm_kern.c

[Maxime Henrion]

M. Warner Losh wrote:
> 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.

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