From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 07:59:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E75D16A4CE; Sun, 1 Feb 2004 07:59:06 -0800 (PST) Received: from ftp.bjpu.edu.cn (ftp.bjpu.edu.cn [202.112.78.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E9143D1D; Sun, 1 Feb 2004 07:58:57 -0800 (PST) (envelope-from junsu@delphij.net) Received: by ftp.bjpu.edu.cn (Postfix, from userid 426) id 7E5465358; Sun, 1 Feb 2004 23:58:55 +0800 (CST) Received: from beastie.frontfree.net (beastie.frontfree.net [218.107.145.7]) by ftp.bjpu.edu.cn (Postfix) with ESMTP id 0AF7C5299; Sun, 1 Feb 2004 23:58:55 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 426) id 52EA011B1D; Sun, 1 Feb 2004 23:58:53 +0800 (CST) Received: from shasujunmv (unknown [211.161.222.116]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 730FB11925; Sun, 1 Feb 2004 23:58:52 +0800 (CST) Message-ID: <017b01c3e8dc$454513f0$74dea1d3@shasujunmv> From: "Jun Su" To: "Peter Jeremy" References: <20040129134121.GB53644@frontfree.net> <20040129200442.GA52780@VARK.homeunix.com> <01bd01c3e742$093d83b0$56dea1d3@shasujunmv> <20040131215006.GP908@cirb503493.alcatel.com.au> Date: Sun, 1 Feb 2004 23:58:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: hackers@freebsd.org cc: current@freebsd.org cc: David Schultz cc: Olivier Houchard Subject: Re: Call for testers: New PID allocator patch for -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 15:59:06 -0000 ----- Original Message ----- From: "Peter Jeremy" To: "Jun Su" Cc: "David Schultz" ; "Xin LI" ; ; "Olivier Houchard" ; ; "John Baldwin" Sent: Sunday, February 01, 2004 5:50 AM Subject: Re: Call for testers: New PID allocator patch for -CURRENT > On Fri, Jan 30, 2004 at 11:02:08PM +0800, Jun Su wrote: > >I think this algorithms for proc_alloc, pfind and zpfind are all O(1). The > >worst situation is that > >it reaches PID_MAX. In this situation, we need expand our pidtbl. This may > >bring some delay. However, this situation will only occurs few times. If a > >machine need 1000 concurrent process, it will only need a 2 ^ 10 slots > >process table. From the original 2 ^ 5 table, we need only 5 times to expend > >the table. > > What was the reason for picking an initial value of 32? A typical > -CURRENT system will have more than this many processes running by the > time rc.d is finished. A more reasonable initial value would seem to > be 2^7. Compaq/HP Tru64 uses a similar pid allocation strategy and it > appears to start with a table of around 2^10. > The value is from netbsd. I didn't give much thinking here. Thank you. > The memory requirements for embedded systems could be reduced by making > the initial value tunable - either at boot time or config time. > Good point. I will try to add this as a config value. > >> [2] Many systems have a high enough fork rate that pids recycle > >> every few minutes or hours with the present algorithm. These > >> systems don't necessarily have lots of processes running at any > >> given time, so the table (and thus the cycle length) in your > >> patch could remain relatively small if I'm interpreting the > >> code correctly. I think the code would have to be changed to > >> prevent reuse from happening too quickly in wall time. > >Reusing the proc slot doesn't mean reusing the pid. Everytime we > >reuse a proc slot, we will add pidtbl_mask to the pid. We reuse > >the pid when the pid reach the max_pid. Therefore if a user wants, he can > >increase > >the max_pid to a larger number to increase the period that the pid is not be > >reused. I will add a sysctl to allow user to adjust max_pid. > > I don't believe it's reasonable to just create a max_pid sysctl and > expect users to tune this to avoid obscure system misbehaviour. > > If the maximum number of simultaneous processes is just below a power > of two then there are very few free slots. These slots will therefore > be reused very rapidly. Even taking into account the pid_tbl_mask, > the pid's could be reused quite rapidly - especially since pid_max > may only be twice pid_tbl_mask. Yes. You are right. In this scenerio, the pid reuse will rapidly. > > The code does include a comment "ensure pids cycle through 2000+ > values" but it's very unclear how this actually works - pid_alloc_cnt That comment is from netbsd... I also am confused about that. > is just a count of the used slots in pid_table and pid_alloc_lim > starts off as the size of pid_table and either doubles or triples > whenever the pid_table size doubles. I can't see any mechanism to > ensure any minimum pid cycle length longer than 2. > > Note that many system utilities "know" that pids can be represented > in 5 digits and having max_pid exceed 99999 will disrupt output from > top, ps, lsof, pstat etc. This places an upper limit on how high > max_pid can be realistically tuned. I did this check in my new patch. I will post my new patch later. > > Rather than doubling the size of pid_table only if the existing table > is full, you need a mechanism to also double the pid_table size and/or > increase max_pid if pids are reused too quickly. A simple check would > be ((pid_tbl_mask - pid_alloc_cnt) * pid_max / pid_table_mask < N) > [for some suitable N]. It would be nice if N depended on the fork() > rate but this may make to code sensitive to fork bombs. Good suggestion. I will try to implement this. Appreciate your feedback. Jun Su > > Peter > >