From owner-freebsd-hackers Tue Oct 24 20:21:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA23710 for hackers-outgoing; Tue, 24 Oct 1995 20:21:13 -0700 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA23704 for ; Tue, 24 Oct 1995 20:21:09 -0700 Received: (from bugs@localhost) by ns1.win.net (8.6.12/8.6.9) id XAA00130 for hackers@freebsd.org; Tue, 24 Oct 1995 23:25:16 -0400 From: Mark Hittinger Message-Id: <199510250325.XAA00130@ns1.win.net> Subject: re: process migration To: hackers@freebsd.org Date: Tue, 24 Oct 1995 23:25:14 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1734 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. Its a big problem but a neat idea. Good Luck! Regards, Mark Hittinger Internet Manager WinNET Communications, Inc. bugs@win.net