From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 8 Jan 2014 11:55:26 -0500 To: 9fans@9fans.net Message-ID: <421bd46d53070799c40d875abe2af588@coraid.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Maximal number of processes Topicbox-Message-UUID: b0a8459e-ead8-11e9-9d60-3106f5b1d025 > In general, you will find that 2000 is the highest allowable due to > limits imposed by proc.c. Other architectures can (and will) place > additional restrictions. A non-FCSE ARM implementation could elect to > only support 256 processes to avoid additional switching overhead for > example. i had a different interpretation of the op's definition of "hard", since memory limits were deemed irrelevant. what limits are you thinking of in proc.c? the only hard limit in the portable code that i see is in devproc.c, the number of processes needs to fit in the space reserved in the qid. i'd forgotten about that since its 2^23, which is so large that it might safely be forgotten. there are plenty of soft limits in the portable code. linear scans of the process table are made in a number of places, for example. and of course process allocation must be static due to the locking schemes used. (cf. the recent procalarm discussion.) - erik