Date: Thu, 3 Sep 1998 02:54:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cyouse@artemis.syncom.net (Charles Youse) Cc: tlambert@primenet.com, abial@nask.pl, freebsd-current@FreeBSD.ORG Subject: Re: VM question Message-ID: <199809030254.TAA08467@usr07.primenet.com> In-Reply-To: <Pine.NEB.3.96.980902225553.25736A-100000@artemis.syncom.net> from "Charles Youse" at Sep 2, 98 10:56:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > To solve the first, you will have to invent a mechanism, whereby an > > application can be asked to free up "dirty" pages, which contain cached > > data that can be regenerated or otherwise recovered without keeping > > them, and to free allocated memory, defrag it, and sbrk the freed > > memory back to the system. > > This sounds hauntingly similar to WIN32 WM_HIBERNATE messages (which, as > far as I know, are only used on CE devices). There was a long drawn out discussion on -current about this; the idea was to make "some processes more equal than others", when it came time to feel the scythe of the VM grim reaper. The approach suggested was to use AIX "getting low on swap" signals, and send "die-unless-you-established-a-handler-and-are-priviledged" to processes (if everyone was priviledged, then it falls back to random mayhem). One of the problems with this is that, when you get an out of memory condition by getting a fault you can't satisfy, you can't signal the process you are faulting, since it can't run until you satisfy the fault, and that basically means you have to put it to sleep, effectively "half-faulted". This would be heavy code to get right. Another alternative would be to "never overcommit memory". This requires that programs have fixed maximum sizes that they promise to adhere to, and that you back with swap (or RAM) all pages that can possibly become dirty. If you couldn't commit dirty-page and memory use backing, then the program fails to start. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199809030254.TAA08467>