Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750748AbWBQVVZ (ORCPT ); Fri, 17 Feb 2006 16:21:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750792AbWBQVVZ (ORCPT ); Fri, 17 Feb 2006 16:21:25 -0500 Received: from warden-p.diginsite.com ([208.29.163.248]:29411 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id S1750748AbWBQVVY (ORCPT ); Fri, 17 Feb 2006 16:21:24 -0500 Date: Fri, 17 Feb 2006 13:20:36 -0800 (PST) From: David Lang X-X-Sender: dlang@dlang.diginsite.com To: Jan Engelhardt cc: Jesper Juhl , "Eric W. Biederman" , "linux-os (Dick Johnson)" , Linux kernel Subject: Re: pid_t range question In-Reply-To: Message-ID: References: <9a8748490602091213p2e020355ue516d59b7d0b6c81@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1675 Lines: 37 On Fri, 17 Feb 2006, Jan Engelhardt wrote: >>>> Any of those 3 scheemes should keep pids below 6 digits as much as >>>> possible. We can still hit the cosmetic problem on boxes where more >>>> than 99999 processes are actually running at the same time, but most >>>> users will never encounter that. >>>> >>> I'd say let's remain doing whatever we're doing now. That is, a maximum of >>> 32768 concurrent pids, and whoever needs more (e.g. Sourceforge shell, >>> etc.) can always raise it to their needs. >> >> when you say 'continue doing what we are doing now' do you mean to include the >> hard-coded limit of 32K pids? or do you mean to not worry about the cosmetic >> issue and change the code to not hard-code the limit, but instead honor a >> max_pid >32K? >> > Stay with the 32K limit. I doubt the majority of users ever exceeds > creating 32767 simultaneous processes. I agree that the mojority of users don't hit this limit, but I've got a couple of boxes that push it (they run out of ram before that, but more ram is on order). however it sounds like switching to a 64 bit kernel will avoid this limit, so I'll put my efforts into configuring a box to do that. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/