From owner-freebsd-arch@FreeBSD.ORG Wed Mar 26 09:13:32 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 5632B37B408 for ; Wed, 26 Mar 2003 09:13:32 -0800 (PST) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6870643F85 for ; Wed, 26 Mar 2003 09:13:31 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 24290 invoked from network); 26 Mar 2003 17:13:35 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 26 Mar 2003 17:13:35 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h2QHDPOv099395; Wed, 26 Mar 2003 12:13:26 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200303260858.37039.wes@softweyr.com> Date: Wed, 26 Mar 2003 12:13:25 -0500 (EST) From: John Baldwin To: Wes Peters X-Spam-Status: No, hits=-19.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES 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 17:13:33 -0000 On 26-Mar-2003 Wes Peters wrote: > 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. I mean that you should be setting P_PROTECTED in fork() based on the inherited rlimit's since otherwise the value of the rlimit is out of sync with the P_PROTECTED flag. Hence a bug. However, since non- inheritance is the desired behavior, it is also a feature, hence "feature" bug. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/