Re: openmosix-2.6

Robert,

   IPC is an entirely different thing. 

 It's also not a clock sync problem.  One real example is if a process
has migrated and sends a system call back to its home node, it's
expecting the next received data to be a response to that system call.
If the home node forwards a signal, 'SIGHUP' for example, the remote
process will crash as it thinks that signal is the response to the
system call.  If the home node sends a migrate home command, the same
problem.   
 
   The kernel daemon is another layer but the tradeoff is small.
Instead of each process handling its own communications and network
sockets, a single kernel daemon handles it all.  

The move to userspace is separate from this.  Whatever decides to
migrate a process is independent from the functionality that actually
migrates the process.  

The actual migration involves copying the process context, the memory
space, cpu register values, etc to another computer that creates a new
process with that information.  This is entirely seperate from the
decision to move the process.  The latter answers the question 'Who
moves'.  The former answers 'How exactly.'

Matt


On Sat, 2006-07-08 at 20:28 +0000, pogson  wrote:
> Matt wrote:
> 
> > Hi Felipe, Gianluca, et al,
> > 
> >    Regarding 2.6.   
> > 
> > One of the problems with 2.6 is that communications between remote
> > and home nodes isn't done very well.  There are race conditions and
> > no synchronicity between nodes, so it's very easy for a process to
> > crash.
> 
> This is a saddening surprise. I suspected there were problems from the
> length of time it was taking.
> 
> The fix proposed seems like an unnecessary layer. This is open source.
> Are there not examples of similar inter-process communication that can
> be adapted? Would synchronicity help? How about synchronizing clocks
> in the manner of ntp and working on even/odd or phased clock time
> quanta? That might not scale or work well in different networks but
> with some tuning it would surely eliminate racing. This could be a
> problem where the speed of transactions must be very high. Should
> OpenMosix be that general? Perhaps limiting it to slower environments
> is necessary. Migration and monitoring should not need to be that
> quick. Transferring data should be as fast as possible. Are the
> methods from the TCP stack too slow? Send a packet. Wait for a
> response. When patience runs out, send again.
> 
> Recently, I have been looking at high-availability clusters. It seems
> to me the actions of OpenMosix and HA are similar in that under
> certain conditions on one node, changes must be made on another. They
> do that simply with Heartbeat for two nodes. OpenMosix is much more
> interesting, but should not some of the same techniques work? Can any
> size of network be made up of  two-node clusters?  Cannot a node be a
> cluster?  
> 
> Perhaps I am naive, but I thought going to userland for most things
> was supposed to make life easier, or at least, limited only by our
> imaginations. 
> 
> I hope some of my rant will help stimulate discussion/ideas.
> 
> Thanks, all
> Robert
> -- 
> A problem is an opportunity.



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642