From owner-freebsd-arch@FreeBSD.ORG Wed Mar 26 08:58:40 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 3571437B404; Wed, 26 Mar 2003 08:58:40 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8179C43F93; Wed, 26 Mar 2003 08:58:39 -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 7ADF6436D4; Wed, 26 Mar 2003 08:58:38 -0800 (PST) From: Wes Peters Organization: Softweyr To: John Baldwin Date: Wed, 26 Mar 2003 08:58:37 -0800 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303260858.37039.wes@softweyr.com> X-Spam-Status: No, hits=-26.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,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) cc: Poul-Henning Kamp 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: Wed, 26 Mar 2003 16:58:42 -0000 On Tuesday 25 March 2003 08:34, John Baldwin wrote: > On 25-Mar-2003 Wes Peters wrote: > > On Monday 24 March 2003 08:36, Poul-Henning Kamp wrote: > >> 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. > > rlimit's are inherited. However, due to a "feature" bug in your patch, > the P_PROTECTED flag doesn't get turned on when the rlimit is inherited > in fork1(). feature bug? If you mean the fact that the setting for P_PROTECTED isn't stored in the rlimit, that was intentional. rlimits are inherited and I specifically didn't want that behavior, similar to p_cpulimit. I still agree resource limits are not an ideal interface to use for this, I'll look further. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com