Date: Tue, 17 Feb 2004 08:54:21 +0100 From: Maxime Henrion <mux@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: des@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_kern.c Message-ID: <20040217075421.GF35475@elvis.mu.org> In-Reply-To: <20040216.174604.89900183.imp@bsdimp.com> References: <20040216210503.GC35475@elvis.mu.org> <20040216.142540.32721629.imp@bsdimp.com> <20040216214602.GD35475@elvis.mu.org> <20040216.174604.89900183.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > In message: <20040216214602.GD35475@elvis.mu.org> > Maxime Henrion <mux@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. Cheers, Maxime
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040217075421.GF35475>