From owner-freebsd-arch@FreeBSD.ORG Fri Mar 28 09:10:38 2003 Return-Path: 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 9C99937B401; Fri, 28 Mar 2003 09:10:38 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D15DE43F93; Fri, 28 Mar 2003 09:10:37 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 0C6A843B68; Fri, 28 Mar 2003 09:10:36 -0800 (PST) From: Wes Peters Organization: Softweyr To: "Poul-Henning Kamp" , David Schultz Date: Fri, 28 Mar 2003 09:10:32 -0800 User-Agent: KMail/1.5 References: <14382.1048580753@critter.freebsd.dk> In-Reply-To: <14382.1048580753@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_IIIh+WfRJfXpokV" Message-Id: <200303280910.32307.wes@softweyr.com> X-Spam-Status: No, hits=-29.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,PATCH_UNIFIED_DIFF, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-arch@FreeBSD.ORG Subject: Re: Patch to protect process from pageout killing X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2003 17:11:09 -0000 --Boundary-00=_IIIh+WfRJfXpokV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 25 March 2003 00:25, Poul-Henning Kamp wrote: > > 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. > > To tackle them from behind: > > Wes has a proposal for #3 which is a per-process flag which says > "I'm sacred". I think that is a sound principle since that is > usually exactly what people want: Do Not Kill This Process. > > Certain processes already enjoy special protection, pid==1 most > notably, this would just be a way to make the same protection > available to other processes. I'm not happy about using the > resourcelimit code for booleans, and I don't think the flag > should be inherited, but otherwise I'm for the idea. I've reworked my patch to use the madvise(2) syscall, like the original 4.x patch did. I've even documented it, in a man page of all places. Please see attached patch. If nobody objects, I'll commit sometime this weekend. > We have the SIGDANGER proposal for #2, but I think we need to have > two severities: "Out of RAM" and "Out of VM". A program like > fsck would start to recycle cached sectors once we're out of RAM. I'll work with Garance to create a proposal, some pseudocode, something like a design. Then we can bikeshed that. Mike Murphy is helping silently at work, letting me bounce ideas off him and look at the man pages on his AIX machine. > But I have not seen anybody come up with a good proposal for > #1, and that is where the main benefit would be derived: It would > allow processes to be good citizens and adjust to the present > situation. Added to think-about queue... -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com --Boundary-00=_IIIh+WfRJfXpokV--