Date: Mon, 16 Feb 2004 22:46:02 +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: <20040216214602.GD35475@elvis.mu.org> In-Reply-To: <20040216.142540.32721629.imp@bsdimp.com> References: <Pine.NEB.3.96L.1040216140303.63057O-100000@fledge.watson.org> <28938.1076959003@critter.freebsd.dk> <20040216210503.GC35475@elvis.mu.org> <20040216.142540.32721629.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040216214602.GD35475>