Date: Thu, 15 Jul 1999 23:48:41 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: lyndon@orthanc.ab.ca Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit Message-ID: <378DF4C8.5E7B4C44@newsguy.com> References: <199907141938.NAA05484@orthanc.ab.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
lyndon@orthanc.ab.ca wrote: > > All of the arguments I've seen so far assume that one process is > running off and grabbing all the available memory. That may be > the most likely scenario, but it's most certainly not the *only* > scenario. What if you have a whole bunch of "middle sized" processes > running, all using memory efficiently, but in total using 95% of > the available VM. A malloc(5*1024*1024) might work, but I need > 10 MB instead of 5MB. And my memory footprint is just a little > bit bigger than the other guys. Instead of returning NULL to > the malloc() request, *zap* I'm dead. How can you possibly > call that sensible behaviour? No process is killed at malloc() time. A process is killed when (another) process needs more memory and it is not available. > Yes, the machine is under-resourced. I can't help that -- it's not my > machine. The machine belongs to a customer who happens to run my IMAP > software, who also happens to have ignored our sizing guidelines. In > this situation I have no choice but to deal with the low memory > condition, and our code does that, if it's given the chance! At > least give me the opportunity to deal with the situation gracefully. If it was not for overcommit, you wouldn't be running half of what you are running in that machine in first place. So, overcommit is helping you run much more for the same resources. > What if we decided to defer errors from bind just because there > weren't any mbufs available, and later killed the process when it > tried to do network I/O? People would howl bloody murder! (<== this is > rhetorical, folks) Out of mbufs does not result in system deadlock, out of memory does. > The semantics of malloc() have been defined since almost the dawn of > time. From the current manpage: > > RETURN VALUES > The malloc() and calloc() functions return a pointer to the allocated > memory if successful; otherwise a NULL pointer is returned. > > Nowhere does it say that allocated memory might not exist. Nowhere > does it say that I have to touch all the allocated pages to make > sure they are really there. Nowhere does it say process death at > some non-deterministic time in the future might be a side effect > of calling malloc(). And nowhere does it say it does not, of course. But that is beside the point. malloc() works as specified. It is the behavior of the system in a low-resource situation that leads to processes being killed. > Applications are written assuming that malloc() behaves in the > documented manner. It is *not* acceptable to tell applications writers Actually, applications are written assuming that malloc() will not fail, generally speaking. > that they have to provide their own management routines on top of malloc() > (SEGV catchers and the like) if they want the long standing semantics > of malloc() to be preserved. If the current malloc() cannot behave in > the documented and expected manner it needs to be renamed, because > malloc() it most certainly isn't. It's funny how all these FreeBSD systems manage to gain such a good reputation despite such an obvious flaw, isn't it? :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" 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?378DF4C8.5E7B4C44>