cvs commit: src/sys/vm vm_kern.c

[M. Warner Losh]

In message: <20040217075421.GF35475 at elvis.mu.org>
            Maxime Henrion <mux at freebsd.org> writes:
: M. Warner Losh wrote:
: > In message: <20040216214602.GD35475 at elvis.mu.org>
: >             Maxime Henrion <mux at FreeBSD.org> writes:
: > : > 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.
: > 
: > It seems of dubious value then.  If someone is going to call malloc
: > with a verybignumber by mistake, they are just as likely to neglect to
: > put M_SAFE in place.
: 
: Yes, but at least with M_SAFE there is a proper way to handle this
: without enforcing artificial limits...  There's no way to make this work
: without the author of the code doing something about it, otherwise we'll
: end up changing the M_WAITOK semantics.  And we badly don't want to do
: that -- which is why this thread started.

Ummm, I still don't see what it buys you over M_NOWAIT.  You are going
to do something when it fails.  And there's really no good argument
for malloc(bignum) in the kernel.  People that do that will be better
served by using some other interface to the kernel.

Warner