From owner-freebsd-hackers Wed Jul 14 12:38:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 535D414D13; Wed, 14 Jul 1999 12:38:23 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1] (may be forged)) by orthanc.ab.ca (8.9.3/8.9.3) with ESMTP id NAA05484; Wed, 14 Jul 1999 13:38:16 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <199907141938.NAA05484@orthanc.ab.ca> To: Ben Rosengart Cc: "Brian F. Feldman" , freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit In-reply-to: Your message of "Wed, 14 Jul 1999 19:02:00 -0000." Date: Wed, 14 Jul 1999 13:38:16 -0600 From: lyndon@orthanc.ab.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What you don't understand is that no process is going to die unless either > someone is running away (in which case they'll get the bullet) or your > system is horribly misconfigured (in which case you deserve your fate). *Why* the machine is out of memory is not the issue. The issue is what happens when you run out (whether due to stupidity in configuration or otherwise). 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? 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. 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) 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(). Applications are written assuming that malloc() behaves in the documented manner. It is *not* acceptable to tell applications writers 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. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message