another laundry or shopping list

["David L. Nicol" <david@kasey.umkc.edu>]

Jordi Polo wrote:

> > But using /proc to start work, people can focus on what features want
> > there.

Lets mount it, by default and for discussion purposes, at /proc/cluster


> Sorry to be so generic, i have no time now, i'll explain longer tomorrow
> 
> Something that worries me is how will we find the processes (as they go away
> from his node) we have 4 alternatives:


> 3.- The info where the process lives  (i don't thing a process will migrate a
> lot )is updated in the node where the process was born . so we can just ask
> the node that according to the cpid is the local node and there will be the
> info . If that node is down we can use 1 or 2 . I like this alternative most.
> This is like a cache, if the info is not in that node we do a broadcast that
> is a more expensive operation.


I like MOSIX's home-node paradigm.  A processes home node is where it 
started, and the home node is responsible for keeping track of the
process, wherever it goes, so it can send it signals and such, so when
a process moves from one non-home node to another, it has to register
this with its home node.

Meaning in CPID terms, that a signal for a cpid would get redirected
by the home node, which is obvious from the CPID.

That's for process migration.





If all the different pieces operate independently

	remote swap space

	remote storage

	remote CPU

	remote IO

	remote signal delivery

	remote whatever-is-left

and we have standards for them, we can have heterogeneous clusters,
since the only thing you need CPU congruity for is remote CPU.

There could be, say, a Central Swap Server that provides swap space
for all the machines, and stores it in its own /dev/shm, and
we could have cluster-wide absolute memory addressing, towards
a standard cluster-wide memory sharing protocol.


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