From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 10 Jan 2014 09:11:04 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7bb04f6804221704ef9a1b68 Subject: Re: [9fans] Maximal number of processes Topicbox-Message-UUID: b19eb474-ead8-11e9-9d60-3106f5b1d025 --047d7bb04f6804221704ef9a1b68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9 January 2014 08:08, Pavel Klinkovsk=C3=BD = wrote: > By the hard limit I consider something like "maximal capacity of GDT, LDT= " > or something similar, if exists. GDT and even Tss are per-processor; ldt isn't used. As to soft limits, apart from the few linear searches mentioned, which could be eliminated if necessary, for instance by tracking process groups, the main constraint is the kernel virtual address space and physical memory consumed by the KSTACK for each process. It's only 4k (in 32 bit mode) but it might be difficult to handle hundreds of thousands of the things comfortably. I tried 3000, on a lowly Atom with 2 Gb RAM: nova% ps|wc -l 2992 and it seemed fine. Do I hear "more!"? nova% ps|wc -l 3991 nova% cat /dev/swap 2135371776 memory 4096 pagesize 48986 kernel 28594/472345 user 0/320000 swap 35004768/142308320 kernel malloc 0/16777216 kernel draw At that point I decided to quite while I was still ahead. I'd probably need a bit more DRAM to do anything much with all of them (they were only running sleep 60), but that's easy to find. Except that they'll have changed DRAM types again no doubt. --047d7bb04f6804221704ef9a1b68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 9 January 2014 08:08, Pavel Klinkovsk=C3=BD <pavel.klinkovsky@= gmail.com> wrote:
By the hard limit I consider something like "maximal = capacity of GDT, LDT" or something similar, if exists.

GDT and even Tss are per-processor; ldt isn't used.

As to soft limi= ts, apart from the few linear searches mentioned, which could be eliminated= if necessary,
for instance by tracking process groups, the mai= n constraint is the kernel virtual address space and physical memory consum= ed by
the KSTACK for each process. It's= only 4k (in 32 bit mode) but it might be difficult to handle hundreds of t= housands of the things
comfortably.
I tried 3000, on a lowly Atom with 2 Gb R= AM:

nova% ps|wc -l
=C2=A0 =C2=A02992

and it seemed fine. Do I hear "mo= re!"?

nova% ps|wc -l
=C2=A0 = =C2=A03991

nova% cat /dev/swap
2135371776 memory
4096 p= agesize
48986 kernel
28594/472345 user
0/3200= 00 swap
35004768/142308320 kernel malloc
0/16777216 ker= nel draw

At that point I decided to quite while I was stil= l ahead. I'd probably need a bit more DRAM to do anything much with all= of them
(they were only running sleep 60), but that's easy t= o find. Except that they'll have changed DRAM types again no doubt.
--047d7bb04f6804221704ef9a1b68--