From owner-freebsd-arch Tue Mar 25 2:45: 5 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2683037B401 for ; Tue, 25 Mar 2003 02:45:00 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7758A43FD7 for ; Tue, 25 Mar 2003 02:44:59 -0800 (PST) (envelope-from das@FreeBSD.org) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h2PAitah006067; Tue, 25 Mar 2003 02:44:55 -0800 (PST) (envelope-from das@FreeBSD.org) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h2PAisFv006066; Tue, 25 Mar 2003 02:44:54 -0800 (PST) (envelope-from das@FreeBSD.org) Date: Tue, 25 Mar 2003 02:44:54 -0800 From: David Schultz To: Poul-Henning Kamp Cc: Garance A Drosihn , Dan Nelson , Wes Peters , freebsd-arch@FreeBSD.org Subject: Re: Patch to protect process from pageout killing Message-ID: <20030325104454.GA5934@HAL9000.homeunix.com> Mail-Followup-To: Poul-Henning Kamp , Garance A Drosihn , Dan Nelson , Wes Peters , freebsd-arch@FreeBSD.org References: <20030325075342.GA5450@HAL9000.homeunix.com> <14382.1048580753@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14382.1048580753@critter.freebsd.dk> X-Spam-Status: No, hits=-19.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Poul-Henning Kamp : > As I see it, there is a need for several mechanisms: > > 1. A mechanism to export to userland enough information about the > current RAM availability, so that phkmalloc and application > specific code can make intelligent choices before things go bad. > > 2. A mechanism to alert userland to the fact that things _have_ gone > bad. > > 3. A mechanism to influence the "Who do we kill ?" decision once > things have gone from bad to worse. I completely agree, and in my last email I attempted to address the fact that #2 and #3 are distinct, and to say that people shouldn't be complaining about Wes's solution to #3 because it doesn't address #2. For #1 and #2, we could have a SIGVM (your terminology from the *last* time this came up) to notify processes about material changes in global resource availability. Applications could then look at that "kernel info" page upon receiving the signal and take appropriate action. I think the hardest part is getting applications to use a proprietary facility. (For example, look at how few people are using kqueue for all of its advantages.) Certainly it could be added to base system programs, but it would be most useful for applications such as postgresql and apache. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message