Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!star.cs.vu.nl!douglis
From: douglis@cs.vu.nl (Fred Douglis)
Newsgroups: comp.os.misc
Subject: Re: process migration - status and availability
Message-ID: <9739@star.cs.vu.nl>
Date: 17 Apr 91 16:28:26 GMT
References: <10422@pitt.UUCP> <1991Apr14.215738.8745@news.stolaf.edu>
Sender: news@cs.vu.nl
Lines: 28

mike@sachiko.acc.stolaf.edu (Mike Haertel) writes:

>One OS I know of that could easily support migration is Amoeba; it's
>interested to note that the current version of Amoeba supports load
>balancing to control processor allocation at process creation time,
>but does not have any more general migration facilities.  I suspect
>this is a case of getting 90% of the benefits at 10% of the cost.

As the designer of process migration in Sprite, and the person who plans
to implement full process migration in Amoeba, I might as well throw
in my two cents:

	- Process migration is not that hard, once you have transparent
	  remote execution.  As Amoeba already supports the latter, adding
	  migration shouldn't be the other 90% of the cost.  Rather, I'd
	  guess (and I'm hoping) that 90% of the cost has already been
	  paid, and I can put in full migration for the other 10%.

	- You're absolutely right about process creation time being
	  the important point.  I think the general consensus about
	  migration is that it's more useful for other things, like
	  machine autonomy (as in Sprite, with personal workstations)
	  or to move from a machine that's being shut down (TCF/AIX has
	  been used for this purpose). 
--
=============================================================================
     Fred Douglis, Vrije Universiteit, douglis@cs.vu.nl +31 20 548-5777
=============================================================================