[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-cluster
Subject:    Re: Some "crash and burn" idea about clusterwide pid
From:       Jordi Polo <mumismo () wanadoo ! es>
Date:       2001-07-14 7:55:54
[Download RAW message or body]


> Hello all (especially Jordi)

Hello Mulyadi

> Watching long threads about cluster pid, make me eager to deliver some
> ideas, here they are :
>
> 1. Since SSI made some perception to the running apps that they are still
> running on "non SSI" system, so system call related to pid's retrieval must
> be made more "smarter". I mean, if the node which called it was joined into
> a cluster system, then it return cluster wide pid, which I believe everyone
> was agree that is origin node ID + local PID. But, if somehow the node is
> temporarily disconnected from cluster, of course there is no need to use
> cluster wide pid, therefore it just use local PID.

getpid returns a pid_t that is declared as int but only the 15 lower bits 
counts, i guess that a returned PID with 16-31 bits to 0 , means the process 
is local (even if the PID is node-pid , we can reserve node 0 to access local 
pid, so we can't use a node 0 in the system ), if 16-31 are different to 0 
then the pid is a CPID , maybe of ourn own node (i prefer all the local 
processes return node=0 if no  ¿we can check it with getnode?) or another one.
But, i don't like that idea about changing pids if we are not connected, i 
thing returning 0 for node in local processes is cleaner.      

>     The point is, we want to minimize the effort and overhead for some
> system call related to pid. In other word, there is no need to implement
> cluster wide PID's rule for every process, only for process that migrate to
> another node. For this manner, SSI kernel must maintain some additional
> process table that maintain the list which process that has been migrated

what if we hace a process that never migrates but we want to take advantage 
of the CPID IPC? 

> 2. How to get node number?? Well, i think we must have some "DNS" for this,
> in centralized manner if everyone agree. Then, each node kept some
> "ARP"-like table that maintain a temporary table which include some node
> number and its IP that have most number of communication which itself. So,
> if node A talk frequently with node B and C, then it list B and C in its
> table. This way, we can reduce traffic and get easy administration of
> cluster node numbering. Any comment or critics??
>
> Mulyadi Santosa



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

[prev in list] [next in list] [prev in thread] [next in thread]