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 majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
