re[2]: Clusterwide pids

[Greg Freemyer <freemyer@NorcrossGroup.com>]

 >>  > Questions:
 >>  > Given that CPIDs seem to be difficult to fully implement and involve
 >>  > the kernel, but if accomplished can be widely used throughout the
 >>  > OpenSource cluster projects, should a common CPID project be initiated?

 >>  I have seen on the past a path running for 2.0 series for a common PID,
 >>  but I lost the link. Anyway, some people would ask first about if it is
 >>  a good feature -since not all the people think that it is a good idea
 >>  breaking backward compatibility-.

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.

A better question from my optimistic perspective is, how can a CPID solution be implemented with minimal impact.

 >>  > Bruce Walker relates that the SSI for Linux Clusters project has this
 >>  > working, and apparently PVM does as well.  Could either of these
 >>  > implementations, or some other existing implementation, be isolated and
 >>  > made available to the Linux Cluster community as a component?

 >>  PVM uses the CPID as an internal commodity of the virtual machine, and it
 >>  does mapping between the internal common PID and the real PID of the
 >>  machine. Anyway, it runs enterly at userland. I doubt that we could use
 >>  PVM code, but we can get the ideas.

This seems pretty restrictive.  I gather PVM has a limit of 64,000 processes across the entire cluster.  A 100 node cluster could only have 640 processes per node.  

That seems like a pretty big limitation to build in.

I think any core/common cluster infrastructure modules should support at least 100 nodes, and hopefully a lot more than that.

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.

 >>  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:

 >>  pid_t getpid(void);
 >>  pid_t getppid(void);


 >>  but we also provide:

 >>  pid_t_32 getpid32(void);
 >>  pid_t_32 getppid32(void);

 >>  This would mean that the old apps will run, and we can develop new HP
 >>  applications that would make use of the new syscalls.

In addition I would think we should update the appropriate header file

#ifndef LEGACY_PID

#define   getpid()      getpid32()
#define   getppid()    getppid32()

#undef pid_t
typedef    pid_t         pid_t_32

#endif

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.

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.

 >>  For a non-HP kernel, the result of the 16-bits and 32-bits would be the
 >>  same -2 most significant bytes at CPID at 0-.

Agreed, unless my earlier suggestion of a 64-bit pid is given consideration.  In that case I don't know what would happen.

 >>  Yours:

 >>  David




Greg Freemyer
Internet Engineer
Deployment and Integration Specialist
The Norcross Group
www.NorcrossGroup.com


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