From owner-freebsd-arch@FreeBSD.ORG Fri Mar 18 09:41:06 2005 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 0F89416A4CE; Fri, 18 Mar 2005 09:41:06 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 656F943D31; Fri, 18 Mar 2005 09:41:05 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j2I9f4A6030952; Fri, 18 Mar 2005 20:41:04 +1100 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j2I9f1S5022138; Fri, 18 Mar 2005 20:41:02 +1100 Date: Fri, 18 Mar 2005 20:41:00 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: David Xu In-Reply-To: <4239829D.5030202@freebsd.org> Message-ID: <20050318201454.Q1050@epsplex.bde.org> References: <20050315125136.GH9291@darkness.comp.waw.pl> <200503161748.02353.jhb@FreeBSD.org><4239829D.5030202@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Pawel Jakub Dawidek cc: freebsd-arch@freebsd.org Subject: Re: System processes recognition. 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, 18 Mar 2005 09:41:06 -0000 On Thu, 17 Mar 2005, David Xu wrote: > Bruce Evans wrote: >> >> P_SYSTEM for init is bogus since it breaks at least procfs for init. >> procfs may need to be disabled for init for security reasons, but it >> shouldn't be disabled unconditionally. I mainly noticed /proc/1/map >> not existing. >> >> There should be flags like P_KTHREAD as needed to make the properties >> of init independent. > > Removing P_SYSTEM for init will cause it to be swapped out under heavy > memory pressure, we unlikely want to swap out init, otherwise it results > zoombies > can not be recycled immediately, does anyone know that init is already be > locked into memory, e.g, by PHOLD ? As I said, there should be flags like PKTHREAD to control this independently. Perhaps 2 flags to control swapouts and pageouts. Only the stack pages are swapped out and the stack is a small part of the process, so for init it is more important to prevent pageouts. I think PHOLD() only affects swapouts. The comment about it in proc.h doesn't say what it does -- the comment says that PHOLD() holds the U-area in memory, but now there isn't even a U-area. There is an explicit test for init in the pageout daemon. I think this prevents init being paged out, so with my removal of P_SYSTEM for init, init has the strange property of being swappable but not being pageable. The test for init has the same hard-coded assumption on init's pid that I fixed in kern_sig.c in my previous patch in this thread, and there is a worse hard-coded assumptions on pids in the same expression: %%% Index: vm_pageout.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_pageout.c,v retrieving revision 1.268 diff -u -2 -r1.268 vm_pageout.c --- vm_pageout.c 7 Jan 2005 02:29:27 -0000 1.268 +++ vm_pageout.c 18 Mar 2005 09:15:09 -0000 @@ -1193,6 +1237,7 @@ /* * If this is a system or protected process, skip it. + * XXX: unfixed: all style bugs, some pid magic (48). */ - if ((p->p_flag & P_SYSTEM) || (p->p_pid == 1) || + if ((p->p_flag & P_SYSTEM) || (p == initproc) || (p->p_flag & P_PROTECTED) || ((p->p_pid < 48) && (swap_pager_avail != 0))) { %%% Bruce