Date: Mon, 12 Apr 1999 11:05:21 -0400 (EDT) From: Mikhail Teterin <mi@misha.cisco.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: current@freebsd.org Subject: Re: swap-related problems Message-ID: <199904121505.LAA70241@misha.cisco.com> In-Reply-To: <199904120400.VAA15072@apollo.backplane.com> from Matthew Dillon at "Apr 11, 1999 09:00:24 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon once wrote: > If you unset the datasize limit and the program does not exceed > the maximum system-supported datasize limit, malloc() should not > return NULL even if the system is out of swap. Can you explain why? Our malloc(3) is a little fuzzy as to the circumstances under which malloc will fail, but on Solaris, it is more explicit: RETURN VALUES If there is no available memory, malloc(), realloc(), memalign(), valloc(), and calloc() return a null pointer. I consider being out-of-swap as having "no available memory". Wouldn't you? Now, for better diagnostics and for a possibility of smarter applications, they also have: ERRORS If malloc(), calloc(), or realloc() returns unsuccessfully, errno will be set to indicate the following: ENOMEM size bytes of memory exceeds the physical limits of your system, and cannot be allo- cated. EAGAIN There is not enough memory available AT THIS POINT IN TIME to allocate size bytes of memory; but the application could try again later. > The correct solution is to set a maximum datasize limit. That is > what it is there for. I generally unlimit the datasize for root > and set it to around 64MB for all other users. Wait, I want to give all the memory available to a program, but I want it to be NOTIFIED when no more memory is left. True, I can set the limit to the actual amount of my swap, but that would be hard to maintain and still does not solve a problem of running together with some other memory consuming application. The existing situation is sort of like killing a program for trying to write to disk in excess of the user's quota, or for being ready to RUN when the load is 1. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904121505.LAA70241>