From owner-freebsd-arch Mon Mar 24 18: 5:44 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 75D1037B404 for ; Mon, 24 Mar 2003 18:05:41 -0800 (PST) Received: from mail01.stbernard.com (mail01.stbernard.com [64.154.93.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00AFA43F93 for ; Mon, 24 Mar 2003 18:05:40 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com ([192.168.4.61]) by mail01.stbernard.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 Mar 2003 18:05:38 -0800 From: Wes Peters Organization: Softweyr.com To: "Poul-Henning Kamp" Subject: Re: Patch to protect process from pageout killing Date: Mon, 24 Mar 2003 18:05:38 -0800 User-Agent: KMail/1.5 Cc: freebsd-arch@freebsd.org References: <7019.1048523782@critter.freebsd.dk> In-Reply-To: <7019.1048523782@critter.freebsd.dk> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303241805.38175.wes@softweyr.com> X-OriginalArrivalTime: 25 Mar 2003 02:05:38.0430 (UTC) FILETIME=[07B5A1E0:01C2F273] X-Spam-Status: No, hits=-25.6 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_UNCONFIRMED_DSBL,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) 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 On Monday 24 March 2003 08:36, Poul-Henning Kamp wrote: > In message <200303240823.48262.wes@softweyr.com>, Wes Peters writes: > >As promised, here's the patch to protect a process from being killed > > when pageout is in memory shortage. This allows a process to > > specify that it is important enough to be skipped when pageout is > > looking for the largest process to kill. > > > >My needs are simple. We make a box that is a web proxy and runs > > from a memory disk, using flash for permanent storage. The flash > > is mounted only when a configuration write is needed, the box runs > > from the memory disk. We've experienced a problem at certain > > customer sites where bind will consume a lot (~30 MB) of ram and > > then pageout will kill the largest process, which is usually either > > named or squid. This pretty much kills the box. We'd much rather > > have pageout kill off some of the squid worker processes, we can > > recover from that. > > > >Is this a good approach to the problem? Feedback welcome. > > (Ignoring the white-space change) OK, I put them back so the function will be inconsistent again. ;^) They accidentally got shuffled when I move my implementation from just below RLIMIT_CPU (from which it obviously and erroneously heavily borrowed) to put it in numerical order. > I can certainly see the point, but I'm not sure this is the way. > > I am not sure that we want to use the resource limits facility for > booleans, some of the logic sourounding the suser checks may not > hold tight. I had concerns about that as well. In the original (4.4 roughly) implementation I used madvise as the interface, but the madvise interface has changed greatly. It didn't seem worthwhile adding a syscall for this task, so I looked for another reasonable protected interface to ab(use). I'm 100% open to suggestions on the API. > Also, doesn't this result in the flag being inerited with fork() and > thereby negating the effect you are seeking for squid ? I looked through all the places in kern_fork.c where p2->p_flag gets set and didn't see anything that looked like it would inherit P_PROTECTED from p1->p_flag. Did I miss something? I'm obviously a bit of a neophyte in this part of the kernel. -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message