Date: Sun, 18 Apr 1999 03:31:36 +0930 From: Matthew Thyer <thyerm@camtech.net.au> To: Warner Losh <imp@harmony.village.org> Cc: mi@aldan.algebra.com, current@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <3718CC80.11C1BE27@camtech.net.au> References: <199904142340.TAA96857@misha.cisco.com> <199904150432.WAA07661@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
There is obviously a problem when all swap is exhausted. The only solution is to allow the additional memory *use* to succeed AND to warn the sysadmin that ALL virtual memory has been exhausted. The only way to do this is to be able to allocate extra virtual memory. I'd vote for a system that would create swap files in the largest mounted read/write filesystem of type UFS or in the filesystem of my choice. There would be a systctl to set the limits on how much space to allocate. Possibly a setting for size and number of emergency swap files. When the time comes for killing processes, you should be able to specify that certain processes (by name) are "precious" and that processes owned by particular users and/or particular login classes are in the last resort or first resort for killing. I dont think it's worth trying to signal with a different signal because only FreeBSD specific programs will know what to do when signalled in such a manner. I suppose you could signal prior to killing as another layer to my dream system. Warner Losh wrote: > > In message <199904142340.TAA96857@misha.cisco.com> Mikhail Teterin writes: > : Then, one can write a safe malloc, which will install the signal > : handler, and touch every page in the the memory referenced by the > : to-be-returned pointer. If the signal handler is invoked in the > : progress, the to-be-returned memory must be returned back to the > : system and NULL should be returned to the caller. > > This won't work all the time. FreeBSD overcommits swap space and you > may get a SIGKILL even if you've touched all the pages. FreeBSD kills > processes when swap space runs out. > > : However, my (in)ability to propose anything remotely sensible does > : not change the facts established in this painful thread. That our > : malloc does not conform to standards (for whatever reasons), and > : that something should be done about it. That "something" must start > : with documenting the flaw... > > The behavior is documented: > The malloc() and calloc() functions return a pointer to the allocated > memory if successful; otherwise a NULL pointer is returned. > > What the system does when it has resource shortages is beyond the > scope of the ANSI-C standard, so I don't see why you say that > FreeBSD's malloc isn't standard conforming. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- /=======================================================================\ | Work: Matthew.Thyer@dsto.defence.gov.au | Home: thyerm@camtech.net.au | \=======================================================================/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 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?3718CC80.11C1BE27>