Re: re[2]: Clusterwide pids

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

Jordi Polo writes:

> Let us summarize a bit:
> -most people agrees we need unique CPID even if the process is something we 
> know is not going to migrate as init. 

OK, except just call it the PID.

> -that CPID will be node number + local pid

No. You could run out of PIDs this way, especially if you support
process migration. It is better to pass out chunks of PID space or
lists of free PIDs. When a node uses half of its allocation, it can
send a request for more PID space.

We have most of a 31-bit PID space available. We shouldn't waste
this. It would be nice to keep things compact on the smaller
clusters for "ps -efj" being sane, while allowing a higher limit
on the really big clusters.

> - We don't want to recompile userspace apps so we do our own system calls, 
> which  maybe :
> 	* getcpid to get the \302\27764bits? with the standard getpid
> returning the low 32 bits of the CPID
> 	* getnode(pid) with 0 if process if local , nonzero otherwise.
> Then we have a question left: \302\277How we manage to get unique CPIDs ?
> What number node a machine must have, \302\277read it from /etc?
> \302\277read it a la HDLC?

Hell no. Use the regular system call for getpid().

Linus already said the PID will not go past 32 bits.

Assign node number via the kernel command line, or assign it
when the cluster is joined.

Maybe you don't really want a shared PID space. It's not for
everyone. Let's keep this clean: share, or do not share.
The half-assed solutions will haunt us later.

Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/