Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!spool.mu.edu!cs.umn.edu!uc!noc.MR.NET!news.stolaf.edu!sachiko.acc.stolaf.edu!mike
From: mike@sachiko.acc.stolaf.edu (Mike Haertel)
Newsgroups: comp.os.misc
Subject: Re: process migration - status and availability
Message-ID: <1991Apr14.215738.8745@news.stolaf.edu>
Date: 14 Apr 91 21:57:38 GMT
References: <10422@pitt.UUCP>
Sender: news@news.stolaf.edu
Reply-To: mike@sachiko.acc.stolaf.edu (Mike Haertel)
Organization: St. Olaf College; Northfield, MN
Lines: 24

In article <10422@pitt.UUCP> jonathan@cs.pitt.edu (Jonathan Eunice) writes:
>Why isn't process migration common?

Two reasons I can think of right off the top of my head are:

1.  It is probably difficult to retrofit to existing operating systems.
My guess (as someone who is attempting to design an OS for fun) is that
some early design decisions (such as whether to have lots of implicit
per-process state, like Unix) can make or break the feasibility of migration.

2.  The benefits may not be all that great.  For example, is it worthwhile
to migrate a process that is paged to a local disc to another machine from
which it will have to be paged over the network?  Similar questions apply
regarding other kinds of I/O bound jobs.

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.

Personally, I tend to think of process migration as being a good test
of the flexibility of an OS, but not something you really want to use
in practice.