From owner-freebsd-hackers Tue Oct 24 21:07:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25679 for hackers-outgoing; Tue, 24 Oct 1995 21:07:38 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA25671 for ; Tue, 24 Oct 1995 21:07:34 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA18032; Tue, 24 Oct 1995 20:59:29 -0700 From: Terry Lambert Message-Id: <199510250359.UAA18032@phaeton.artisoft.com> Subject: Re: process migration To: bugs@ns1.win.net (Mark Hittinger) Date: Tue, 24 Oct 1995 20:59:29 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199510250325.XAA00130@ns1.win.net> from "Mark Hittinger" at Oct 24, 95 11:25:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2557 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > From: Gavin Lim > > 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.