Date: Sun, 25 Feb 2001 21:29:08 -0800 (PST) From: Archie Cobbs <archie@dellroad.org> To: Warner Losh <imp@village.org> Cc: Peter Seebach <seebs@plethora.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <200102260529.f1Q5T8413011@curve.dellroad.org> In-Reply-To: <200102252201.f1PM1fY00967@billy-club.village.org> "from Warner Losh at Feb 25, 2001 03:01:41 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh writes: > : >OTOH, the *only* way to get non-overcommit to FreeBSD is for someone who > : >*wants* that feature to sit down and code it. It won't happen otherwise. > : > : So, out of idle curiousity: If, somewhere down the road, I know the kernel > : well enough to attempt such a thing, what would the interest level be in > : merging such a feature? > > Assuming that it doesn't break anything, that it doesn't introduce a > severe performance penalty and works, there would be interest. There > are times that this is a desirable feature. This thread reminds me of what happened when I brought up the same issue a few years ago, arguing that the kernel shouldn't overcommit memory (i.e., the same thing, everybody though I was nuts :) For me it helps to understand people's underlying motivation. Here's mine... my perspective probably comes from using FreeBSD in the embedded world, which is very different from using FreeBSD in the rack-mounted server world. One important way to gain confidence that you're little box won't silently crash at the worst possible time for the customer is to be able to *prove* to yourself that it can't happen, given certain assumptions. Those assumptions usually include things like "the hardware is working properly" (e.g., no ECC errors) and "the compiler compiled my C code correctly". Given these basic assumptions, you go through and check that you've properly handled every possible case of input (malicious or otherwise) from the outside world. Part of the "proof" is verifying that you've checked all of your malloc(3) return values for NULL.. and assuming that if malloc(3) returns != NULL, then the memory is really there. Now, if malloc can return NULL and the memory *not* really be there, there is simply no way to prove that your code is not going to crash. This memory overcommit thing is the only case that I can think of where this happens, given the basic assumptions of correctly functioning hardware, etc. That is why it's especially annoying to (some) people. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102260529.f1Q5T8413011>