From owner-freebsd-current Wed Sep 2 19:55:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA29455 for freebsd-current-outgoing; Wed, 2 Sep 1998 19:55:42 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA29450 for ; Wed, 2 Sep 1998 19:55:36 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA28563; Wed, 2 Sep 1998 19:54:33 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd028522; Wed Sep 2 19:54:27 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id TAA08467; Wed, 2 Sep 1998 19:54:21 -0700 (MST) From: Terry Lambert Message-Id: <199809030254.TAA08467@usr07.primenet.com> Subject: Re: VM question To: cyouse@artemis.syncom.net (Charles Youse) Date: Thu, 3 Sep 1998 02:54:20 +0000 (GMT) Cc: tlambert@primenet.com, abial@nask.pl, freebsd-current@FreeBSD.ORG In-Reply-To: from "Charles Youse" at Sep 2, 98 10:56:51 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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