Re: Clusterwide pids

["David L. Nicol" <dnicol@cstp.umkc.edu>]

Greg Freemyer wrote:
> 
> I guess that I am such a cluster convert, that I simply accept that full SSI type clusters
> are the future.  For IPC to ever have a SSI view of the cluster will require CPIDs, so I
> take it as a given that eventually, we will have to have a CPID solution.  My hope is
> that we have just one, not one per cluster technology.

Translation tables work fine.  There has to be a way for the OS to figure
out where
to deliver the signal and deliver it there. Mucking around with the Local
PID to
implement Cluster PID may be overkill.  So what if ps on node seven doesn't
show everything running on node nine?




> 
> Given the Alpha and the imminent arrival of the Itanium, I would prefer to see a 64 bit CPID with the first 32 bits for the node and the last 32 bits for the local pid.
> 
> I don't have Alpha Linux installed on anything right now, so I'm not sure what size pid it uses, but it seems reasonable to me for the 64-bit processors to use a 64-bit CPID.

if the LPID is kept separate and untouched by the clustering code, and the
CPID made
a two-part structure of NodeIdentifier and LPID, local code is left alone
and
clustering code gets the appropriate size CPID depending on the limits of
the clustering scheme (since everyone has node ids of some kind.)


 
>  >>  The main idea would be doing mapping, as PID does. If you ask for a
>  >>  16-bit PID, you reference the local PID. If you ask for a 32-bit PID, it
>  >>  would give to you the global PID. This would mean that all the old
>  >>  application will run, but it also means that we will need more kernel
>  >>  calls. As an example, we keep:

Any bit-counting limits future expansion and portability.  What if I want
to embed the structure with my 4-bit project, just for fun?  Keeping
LPID and CPID as abstract as possible (but no abstracter) allows full
flexibility.


> This would allow a simple recompile would give people a chance to know about the new calls and a fairly easy way to stick with the current pids.

"a simple recomlile"  -- so much for transparency and binary compabability!

 
> In addition, it might be nice to actually say getcpid() and getpcpid() instead of getpid32() and getppid32().  This would make developers more aware of the availability of the cluster infrastructure as opposed to thinking it was a simple pid expansion.

I Agree.  Define them both in terms of a (NodeID, LPID) structure and you
have, FWIW, my full support.


-- 
                                           David Nicol 816.235.1187
                      Irish Government Warning: SMOKERS DIE YOUNGER


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