Date: Tue, 24 Oct 1995 20:59:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bugs@ns1.win.net (Mark Hittinger) Cc: hackers@FreeBSD.ORG Subject: Re: process migration Message-ID: <199510250359.UAA18032@phaeton.artisoft.com> In-Reply-To: <199510250325.XAA00130@ns1.win.net> from "Mark Hittinger" at Oct 24, 95 11:25:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > From: Gavin Lim <gavin@linux1.dlsu.edu.ph> > > We're developing a process migration facility for FreeBSD 2.0.5. Process > > migration is the procedure by which running processes are transferred > > from one computer to another in a network. This would make load sharing > > and load balancing in distributed systems possible. > > In order to transfer a process, we have to save the process state, > > probably save it to a file, and transfer this file to the destination > > computer, where it would be deserialized and converted back to data > > structures. When this is done, the process can resume execution on the > > destination computer. > > This sort of thing has been attempted before in TOPS-10 and VMS. In TOPS-10 > it was called "system sleep" and in VMS it was RUN/CHECKPOINT. > > This would be a very useful feature even in a single processor environment. > If you need to shut the system down for some sort of maintenance, you could > "sleep" the processes and shut down the machine. Then you could reboot > and continue the checkpointed processes. > > It is important to note that these features were beta only and never made > it into an official release (the TOPS-10 one may have). > > Basically the implementation idea was to create a page fault scenario and > page out the entire image. The context of the process would also be saved > in the swap space. > > Then you'd have to copy the swap space context of the process to another > machine, or shutdown/reboot, and then swap the process back in. > > The problems are in file locking, shared memory segments, buffers that > need to be flushed to the file system, etc. There's also other problems: 1) File as swap store. The executable file is acting as its own swap store; this means you must reopen the file (which means you need its name) and reestablish the flags on the vnode to orevent writes to it. 2) Memory overcommit. There very well may not be enough swap to checkpoint the program. 3) Shared libraries. The shared library mappings must be restored, probably seperately. 4) Shared memory, semaphores, etc. 5) Open file descriptors. 6) Network listens (recoverable) and network connections (not recoverable if reliable stream delivery, recoverable for stateless datagrams). 7) Mapped files (other than shared libraries). 8) FIFO/pipe/cooperating process recovery. This is a non-trivial task. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510250359.UAA18032>