Date: Mon, 12 Apr 1999 13:30:00 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Brian Feldman <green@unixhelp.org>, current@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <Pine.BSF.3.95.990412132827.299D-100000@current1.whistle.com> In-Reply-To: <199904120153.SAA12154@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It seems to me that you might kill the forst program the has a lot of ram in unse that has not specified a limit for itself.. programs that are wel enough behaved to set a limit for themselves should be rewarded. just a thought... julian On Sun, 11 Apr 1999, Matthew Dillon wrote: > :I use the memory as soon as it's malloced. If it reserves a page, then > :pagefaults it into existence, the VM system knows that that page is now > :allocated. When I malloc the last available page for user use, the VM > :system knows that it's the last page. I dirty it, and there are none > :free. If I malloc(), I want to know that there is no more memory, not > :have my process killed. This is POMA. > : > :Previously, the POLA, a NULL getting returned, WORKED CORRECTLY. It did this > :for a long time. My little test program always showed this, and shows > :that now something was broken. I'll attach it to the end. > > I ran your program. malloc() appears to work properly -- returns NULL when > the datasize limit is reached. In my case, I set the datasize limit > to 64MB and ran the program. > > ... > mallocs failed at 64956 > > Under 4.0-current. > > :> then one or two processes getting killed. Having N random processes get > :> malloc() failures can lead to serious instability with processes. > : > :Only bad code doesn't check return values of malloc(). > > You are volunteering to run through the thousands of programs & ports > to make sure that every one checks the return value for malloc()? > > Declarations that don't solve problems are not relevant. It's bad enough > that we have to kill something to handle an out-of-vm situation, we > shouldn't go off and destabilize the rest of the system while we are at it. > > -Matt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > 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?Pine.BSF.3.95.990412132827.299D-100000>