From owner-freebsd-arch Mon Mar 24 17:52:47 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 6B15137B404; Mon, 24 Mar 2003 17:52:44 -0800 (PST) Received: from mail01.stbernard.com (mail01.stbernard.com [64.154.93.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 356EB43F75; Mon, 24 Mar 2003 17:52:41 -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 17:52:40 -0800 From: Wes Peters Organization: Softweyr.com To: John Baldwin Subject: Re: Patch to protect process from pageout killing Date: Mon, 24 Mar 2003 17:52:40 -0800 User-Agent: KMail/1.5 Cc: freebsd-arch@freebsd.org References: In-Reply-To: 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: <200303241752.40245.wes@softweyr.com> X-OriginalArrivalTime: 25 Mar 2003 01:52:40.0618 (UTC) FILETIME=[3818F0A0:01C2F271] X-Spam-Status: No, hits=-26.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,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 11:09, John Baldwin wrote: > On 24-Mar-2003 Wes Peters wrote: > > 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. > > I think that adopting the SIGDANGER approach would be better rather > than rolling our own private interface. It's not clear to me the SIGDANGER interface allows me to say "go elsewhere bub, I'm really important." In this case, that is essential. I think even in the general FreeBSD case you can make a point for a setting like this in, say, named. The SIGDANGER interface worries me in general, partly because it's a signal and partly because it complicates the design of EVERYTHING just to handle it. I guess a lot depends on the implementation details of how SIGDANGER and the default handlers are designed, but nothing I saw last week gave me a warm fuzzy about that. > > @@ -625,6 +625,15 @@ > > if (limp->rlim_max < 1) > > limp->rlim_max = 1; > > break; > > + > > + case RLIMIT_PROTECT: > > + mtx_lock_spin(&sched_lock); > > + if (limp->rlim_cur) > > + p->p_flag |= P_PROTECTED; > > + else > > + p->p_flag &= ~P_PROTECTED; > > + mtx_unlock_spin(&sched_lock); > > + break; > > p_flag is protected by PROC_LOCK, not sched_lock. Gurk! Will fix. -- "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