Re: Glibc, large PIDs etc (Was: Killing clones) (fwd)

H. Peter Anvin (hpa@transmeta.com)
27 Aug 1997 06:45:10 GMT

Followup to: <199708261508.IAA05932@kryten.aracnet.com>
By author: Tim Wright <timw@transmeta.com>
In newsgroup: linux.dev.kernel
>
> Ummm...
> no.
> Whilst I don't think Linux users are likely to be hitting the limit too soon
> since I believe the majority of Linux users are using "small" systems, the
> limited size of the process id "name"space is getting close to being an
> issue for large scale Unix systems.
>
> If I have a system supporting 12,000 database users and the database
> architecture uses two processes per user, I've used 24,000 of my 30,000
> available pids (MAXPID is normally 30,000 for SVR4ish systems) or 80%.
> That caps me at < 15,000 connected users. This is a real limit.
>
> The above is not an entirely hypothetical example...
>

Under Linux/i386 it would be, at least, since Linux would need minor
redesign to go beyond 4,000-odd processes and major redesign to go
beyond 8,000-odd; this is because Linux uses i386 TSS, which means
each process needs a slot in the GDT. Right now Linux reserves two
slots per process: one for the TSS, one for the LDT; however, since
very few processes actually need an LDT (at present -- one could
imagine scenarios at which that would change), one could decouple the
two.

The GDT on an i386 processor has 8,191 slots, and Linux uses several
of them for system use.

"Major redesign" would mean ripping out all the hardware-based task
switching and roll our own.

-hpa

-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
Always looking for a few good BOsFH.  **  Linux - the OS of global cooperation
        I am Baha'i -- ask me about it or see http://www.bahai.org/